Birth of a Linux-Distribution

Menu

As you may have sensed by now, we are having problems this year getting out a proper release of the desktop environments we ship. There is more than one reason for that. For one it was really hard to get things in shape for a release. KDE for example was in heavy developement most of the time. Now that we have Plasma 5.8.x with longtime support, things settle down a bit and we will hopefuly get a release of that flavour out until the end of the year. GNOME and Cinnamon are also in steady movement, Xfce and MATE don’t move that much.

On the other hand the time that siduction team members have at their hands have lessened over time. Speaking for myself, my workload has grown a lot during the past two years. Another team member joined a team that took on the job to bring LXQt in shape and into Debian (and they succeeded). A third team member got himself a job whereas before he was unemployed for some time (and of course we are happy for him). All these constraints make it harder to achieve our goals of releasing siduction in the way we did until now. That does not mean in any way that siduction is unmaintained. We steadily work on it as is needed and try to guide you through shallow waters. Just the big tasks like releases get left behind.

There were no new contributors joining the team, so that does not help either. So we have come up with an idea that will lessen our workload a bit. The idea is for flavour maintainers to determine when a flavour is good and ready for release. We know in advance what is going to happen in critical flavours and if there is transitions or other big changes coming up, that might brake things. So, e.g. when KDE seems in good shape to be released to the public, so may be another flavour. Then those two could go out as a snapshot. Possibly a month later some other flavours are good to go.

We found a long time contributor, who is willing to manage these kind of releases. That means checking if the flavour(s) are in releasable shape, coordinate a release and ship them on their way to you. That will help us and our users. You as a user get fresher snapshots as entry points to the distribution, which also attracts new users. For us as the team behind siduction it raises the visibility of the distribution, which also attracts new users and maybe even contributors. So we will give this a try and see how it goes. Like I said before, we hope to get results out before the end of the year.

One other thing that is in dire need of love is our manual. Once a wealth of knowledge, it is now vastly aging and mostly unmaintained. The way it is technicaly set up makes it hard to contribute to and very unwieldy for us to maintain the infrastructure. There is two things to do here: We need to do the heavy lifting of transferring the content to a multilingual wiki like MediaWiki. We have languages in the manual, that are totaly unmaintained because noone in the team speaks the language (nor has the time) to work on these. Those languages are Portugese, Italian, Romanian, and Polish. We still need to decide what to do with them. Right now they are counterproductive because in parts they are by now plain wrong or misleasing. My idea is to archive them until maybe someone later picks up a language.

The second task is to go over all German and English items in the manual and correct them where needed and bring them up to current, also write new ones (e.g. for systemd). All this needs manpower. So if you would like to help with any of this, you are very welcome, please reach out to us on our forum or on IRC on the OFTC network in #siduction-core. Working over the manual can be done as your time allows, there is no ETA to this. We are also always looking for artists. This is also a commitment that does not take up much of your time, it is mostly about creating an icon here and there.

With systemd 230, released a couple of days ago, the developers changed a default setting, that eliminates one of the few annoyances I experienced with systemd. Many a forum thread all over the net tried to solve the problem. This annoyance resulted in a message during reboot or shutdown, that the system is waiting for a process to shut down. This could take up to 90 seconds, if you did not set the level lower manually. These were stray background processes, that belonged to one or more users on the system and should have been shut down, when the owning user gets logged out.

The systemd developers with systemd 230 set the option KillUserProcesses in /etc/systemd/logind.conf to yes. That means that 95 percent of desktop users will not see these delays anymore, because all processes of a user will be closed when the user gets logged out. On the other hand, users of tools like screen, tmux and some others will find their processes also killed server-side, even though these were meant to be long-running background jobs. That being said, the devs did explain in the release note for systemd 230 under the third bullet, what users of such tools need to do to keep KillUserProcesses on yes and still have their long-running jobs stay alive. The problem at hand was being layed out in detail in a bugreport and it’s follow-up discussion already in April.

In Debian and Fedora this new behaviour led to long discussions (and the usual systemd laments of course). The bug report for Debian on this matter now led to the new standard setting being reverted in Debian with systemd 230-2 as of today. So, if you like your processes being stopped when your user logs out, you need to manualy revert the setting in /etc/systemd/logind.conf to yes again after updating to systemd 230-2. We decided months ago to have this set to yes as default for siduction. This will take effect with our next release. But if you want to set this to yes now, you need to do so yourself.

Should you be one of the users of screen, tmux, mosh and maybe a few other affected tools, there is ways to keep the setting at yes and still keep long running processes alive when logging out. You need two things to do this: first you set enable-linger [USER1 USER2...] for your respective users, as shown in the manpage to loginctl. PAM has been adapted to allow this as normal user. Then you can follow the manpage of systemd-run to start e.g. screen with the command systemd-run --scope --user screen in it’s own scope. This will keep the job running after logout, even though other user processes are stopped.

We admired Debian for deciding pro systemd, but we think, reverting this new default is the wrong decision in the face of desktop users.

We present to you today the second part of the dev-release 2015.1, which, with it’s final release in a couple of weeks will be named siduction 2016.1. siduction is a distribution based on Debian’s unstable branch. With a heavy heart we dedicate this release to the memory of the founder of Debian, Ian Murdock, who passed away on Dec. 28 2015, aged 42. We will try to keep his vision alive.

Important for testing in VirtualBox: Due to a bug in VirtualBox 3D-acceleration has to be disabled prior to booting the image.

The missing flavours of the first batch of dev releases are Plasma 5, GNOME and LXQt, which we present to you today. Before looking into the changes of our three released flavours, here are some changes to our infrastructure that you should be aware of:

First of all, 32-Bit versions will be shipped with the final release only. If you need one now, come see us at #siduction on IRC and we will build one for you.

After long discussions that go back as far as two years, we have finaly made the decision to ship with contrib and nonfree enabled and most of the nonfree-firmware preinstalled to enable the user to use his wifi chip or graphics card right from the start without the need to aquire software without being able to have an internet connection on the device you are installing on. Because of this, save settings are not needed anymore for AMD graphic cards. The menu item will be moved from Syslinux for the final release.

Disclaimer

You need to be aware that this new behaviour is not in accordance with the Debian Free Software Guide (DFSG). We offer an opt-out from this to go back to a DFSG-compliant installation in the installer.

Changes to our release model

Besides that, we will slightly alter our release model. During 2015 we learned that with as many flavours as we ship and with the ressources we can use, we find it very hard to release all flavours together in one release. That resulted in no release at all for 2015, which leaves new users with growing first upgrades as the year moves on. To prevent that from happening again, in the future we will release flavours as soon as they are ready and benefit the user. We will still try to release more than one at a time, but not wait for a chance to release all of them together.

SDDM

Another change over all flavours is the use of SDDM as Display- and Login-Manager, which is the new default for LXQt and KDE, but suits the other flavours fine as well. KDE has a module for SDDM in the system settings. For the other flavours, find the config file in /etc/sddm.conf. The manpages to sddm and sddm.conf are also quite helpful.

UEFI

Also the images released today have very basic support for UEFI. You can boot with it and install with it. Prerequisites are a partition layout with GPT and a boot partition formatted with Fat32 and marked as efi partition. Grub with UEFI still needs some love, so this functionality is still highly experimental. Find out more here

A brief look at the flavours

The released images are a snapshot of Debian unstable, that also goes by the name of Sid, from 2016-01-16. They are enhanced with some useful packages and scripts, our own installer and a custom patched version of the linux-kernel 4.4, accompanied by X-Server 1.17.3, Mesa 11.1.1-2 and systemd 228.4

Plasma 5

Friends of KDE will be happy to see our first release of the fifth iteration of the project. People will keep calling it KDE5, but that will prove to be not saying much about the contained parts. As we have done now for siduction, KDE has decided some time ago that the KDE Software Collection is getting much to unwieldy to release in one piece. To bring new code to the users as fast as possible, KDE was broken up into three parts that are developed and released independently from now on. These are KDE Frameworks, Plasma and KDE Applications. The part that the user actualy is in touch with is Plasma and so we will call the latest KDE Plasma 5. KDE Applications is shipped in version 15.08

We were hoping to be able to ship Plasma 5.5 or even 5.6, but the holidays delayed things to the point where we decided to ship Plasma 5.4.3 with the dev release and probably 5.6, which will have a lot more fine tuning to it, with our final release.

KDE-Next

From now on the base of our KDE releases is Debian unstable. We had to close down our KDE-Next repository, because it is not maintained anymore. Our thanks go to Santa, who packaged KDE for siduction in the past and will from now on work directly with upstream. We wish him the best of luck on his way.

With Plasma 5.4.3 we believe we have the most elegant KDE of all times. More importantly, it is ready to be used in production for most users. There will be some tidying over the next few months still, but basicaly it is ready to rock.

Plasma Dash

One of the novelties of Plasma5 is not easily discovered on first sight. That’s why I like to introduce it here. Plasma5 gained a third menu, which is accessible if you right click K-Menu and hit Alternatives. There you find a fullscreen dash with integrated desktop search, which is fully usable just with a keyboard.

LXQt

A lot has also happened regarding LXQt. As you might know, our own Alf Gaida is involved in the developement of LXQt. In the course of that in 2015 he became official Debian Maintainer to be able to easier get LXQt into Debian and maintain it there. As a result of these efforts, LXQt is now in Debian Unstable and Testing, the current version being a freshly released, hot off the plates 0.10.

GNOME

Last but by no means least with GNOME we have the antidote to KDE. GNOME is shipped in a well matured version 3.18. One of the highlights is that you can run a Wayland session from the login page of the display manager. There is still a few crashes and glitches involved, but mostly, Wayland runs quite stable with GNOME.

Our Resources

Support can be obtained on our forum as well as on IRC. The relevant channels on
OFTC-Network are #siduction for english support or #siduction-core, if
you like to join in and participate. On your desktop you also find an icon that takes
you to the right channel for support, depending on the chosen language.

To be able to act as a testbed for Debian, we are making us of our own bug-tracker.
Let me explain how you can help us and Debian by submitting bugreports for broken
packages. Weathered users will know how to file bugs directly with the Debian BTS
(Bug Tracking System). For users not so comfortable with the system we havereportbug-ng preinstalled.

If you think, you found a bug in a Debian package,
please start reportbug-ng and put the name of the package in the adressline on
top. The app will now search through the already filed bugs for that package and show
those. Now it’s up to you to determine, if “your” bug has already been reported. If
it is, ask yourself if you have anything relevant to add to this report or maybe even a
patch. If not, you are done for this time. If the bug has not been reported yet
and you are not familiar with the BTS yet, you may report the bug in our
Bug-Tracker.

That obviously goes for siduction packages as well. We will sort the bugs for you
and file them in the appropriate place, if it’s reproducible. Please look out for
a forum post with more detailed info on the bug-tracker soon. If all this seems
to complicated for now, feel free to use the bugs-thread on the forum for now,
it will keep working until final release.

As we are always looking for contributors, here is what to do: Come to IRC to
channel #siduction-core and talk to us about what you would like to do within
the project, or where you think you could help. As you will notice if you scroll down, we have no art-team at the moment. If you are willing and capable, talk to us.

Hardware Tips

If you should own a ATI Radeon graphics accelerator, please use the failsafe option, when booting the Live-ISO. This option will add the cheatcodes radeon.modeset=0 xmodule=vesa to the Kernel bootline, so that you can boot to X.

Last but not least a hint for users of the kernel based virtual machine KVM. The developement of a frontend for the kernelbased virtual machine (kvm) has begun as a fork of qemu with the name qemu-kvm or short “kvm”. Since qemu version 1.4 all patches of the kvm fork have been integrated back into the qemu source. Also there has been much progress in the field of virtualization. So there is a lot of outdated documentation around. We have a current worksheet for Qemu in our wiki.

Release Notes for siduction 2015.1 Dev-Release

We present to you today a dev-release at the last possible point in time for this year and inform you of some changes in our release model. siduction is a distribution based on Debian’s unstable branch. With a heavy heart we dedicate this release to the memory of the founder of Debian, Ian Murdock, who passed away on Dec. 28 2015, aged 42. We will try to keep his vision alive.

For 2015 we can just release this dev-release, even though we would have liked to do more. Due to the course that Debian Unstable and some desktop environments took over the course of the year, we had no chance to get a release ready with all flavours, following our release model. So we need to make a change here and release flavours when they are ready to release and not wait for the other flavours. Following the old release model, we now sit on final images released one year ago, where the first upgrade is bigger than the image itself. That is a far from ideal situation, hence the change.

Today we present dev-releases of noX, Xorg, LXDE, Cinnamon, Mate and Xfce. Plasma 5, GNOME and LXQt will follow on the weekend or shortly after, given there is no blockers.

Even though these release notes do not go into depth, there is one change I need to communicate. After long discussions that go back as far as two years, we have finaly made the decision to ship with contrib and nonfree enabled and nonfree-firmware preinstalled to enable the user to use his wifi chip or graphics card right from the start without the need to aquire software without being able to have an internet connection on the device you are installing on.

Disclaimer

You need to be aware that this new behaviour is not in accordance with the Debian Free Software Guide (DFSG). We offer an opt-out from this to go back to a DFSG-compliant installation. For the dev-release, apt purge $(vrms -s) -s shows you the installed packages. Running the command without the -s will remove them all. For the final release we will ship a more comfortable solution.

The released images are a snapshot of Debian unstable, that also goes by the name of Sid, from 2015-12-31. They are enhanced with some useful packages and scripts, our own installer and a custom patched version of the linux-kernel 4.3, accompanied by X-Server 1.17.3. and systemd 228.2

Besides the desktop environments we also ship noX, which is an environment without X and Xorg which features the minimal window manager Fluxbox on top of X.

A brief look at the flavours

Xfce is the reliable work horse it always was, shipping in Version 4.12.2. The same goes for LXDE, a lightweight desktop, that just works. Xorg and noX need no further words, they are special purpose releases for people who like custom installs. MATE is following the tracks of GNOME 2. We ship version 1.10.2.1, which is stable enough to work with Cinmnamon, which follows GTK 3 rather than 2, ships with version 2.6.13.1.

Our Resources

Support can be obtained on our forum as well as on IRC. The relevant channels on
OFTC-Network are #siduction for english support or #siduction-core, if
you like to join in and participate. On your desktop you also find an icon that takes
you to the right channel for support, depending on the chosen language.

To be able to act as a testbed for Debian, we are making us of our own bug-tracker.
Let me explain how you can help us and Debian by submitting bugreports for broken
packages. Weathered users will know how to file bugs directly with the Debian BTS
(Bug Tracking System). For users not so comfortable with the system we havereportbug-ng preinstalled.

If you think, you found a bug in a Debian package,
please start reportbug-ng and put the name of the package in the adressline on
top. The app will now search through the already filed bugs for that package and show
those. Now it’s up to you to determine, if “your” bug has already been reported. If
it is, ask yourself if you have anything relevant to add to this report or maybe even a
patch. If not, you are done for this time. If the bug has not been reported yet
and you are not familiar with the BTS yet, you may report the bug in our
Bug-Tracker.

That obviously goes for siduction packages as well. We will sort the bugs for you
and file them in the appropriate place, if it’s reproducible. Please look out for
a forum post with more detailed info on the bug-tracker soon. If all this seems
to complicated for now, feel free to use the bugs-thread on the forum for now,
it will keep working until final release.

As we are always looking for contributors, here is what to do: Come to IRC to
channel #siduction-core and talk to us about what you would like to do within
the project, or where you think you could help. As you will notice if you scroll down, we have no art-team at the moment. If you are willing and capable, talk to us.

Hardware Tips

If you should own a ATI Radeon graphics accelerator, please use the failsafe option, when booting the Live-ISO. This option will add the cheatcodes radeon.modeset=0 xmodule=vesa to the Kernel bootline, so that you can boot to X.

Last but not least a hint for users of the kernel based virtual machine KVM. The developement of a frontend for the kernelbased virtual machine (kvm) has begun as a fork of qemu with the name qemu-kvm or short “kvm”. Since qemu version 1.4 all patches of the kvm fork have been integrated back into the qemu source. Also there has been much progress in the field of virtualization. So there is a lot of outdated documentation around. We have a current worksheet for Qemu in our wiki.

Six siductioneers spent the last weekend at CLT 2015, the annual Linux conference at Chemnitz University. First of all, let me thank the people who organized this conference for the 17th time and of course all the helper bees that make it the most pleasant event on the annual Linux calendar. Just to give you an idea, here is some numbers. Besides a lot of workshops, more than 90 talks on a wide variety of subjects were held, 60 projects like siduction could exhibit the soft- or hardware or the services they offer. Between the two days of work and hacking, Linux-Night offers socialising, food, drink and music. It was nice to see that the place was packed and bursting at the seams with visitors on both days.

We had a successful weekend and tons of fun. Besides answering questions or solving problems of visitors at our booth we were able to roll out some ideas for the future of siduction that you will learn about soon. Besides that we were paid a visit by some people from the distant past of our project. Klaus Knopper and also Kano from Kanotix came by our booth to say hello. Knopper was doing some inquiry on how to tame systemd for Knoppix, which is not all that easy due to the nature of the scripted way in which Knoppix boots. We were able to provide some help and advice here and put aside some of his worries in that regard. Both of them might be helpful to us in porting siduction to ARM devices. We supplied Kano with a developer board where he can play with porting stuff from other architectures. So with Knopper and Kano there and our pals from Debian right next to us, we had the full circle from the Knoppix/Kanotix origins to Debian Stable and beyond to the save haven of siduction.

Besides that we managed to talk to our server provider Hetzner, whose company was also present with a booth. They will upgrade our hardware for web- and buildserver in the course of 2015 free of cost and for the same fee as we pay now. We also worked on some ideas on how to attract new developers to siduction, which is a problem that in the long run we will need to solve for sure. Too much work is on just a few shoulders right now. Things we need to attack soon involve UEFI installs and, regarding the latest news from linux-loving Microsoft, we might have to deal with secure boot as well. One of the ideas to attract new blood is to rent another server and donate slices of that to developers and projects who need some iron to work on for a fixed time frame. Our terms for this would be, that people who want to use our offer at least have a look at our project and consider a list of problems we want to tackle and help a bit with that, if they can.

What we did not do on this weekend was taking pictures. I left my camera at home and noone else had one either. So this article has the only photo of our booth that I could find on the net. But that is ok, facts are more important than pics :). Some Debian folks invited us to DebConf, which is held in August for the first time in Germany. Besides that we will visit another young Linux fair called Open-Rhein-Ruhr and that takes place in November in the city of Oberhausen.

We are very happy to present to you the final release of siduction 2014.1 – Indian Summer. siduction is a distribution based on Debian’s unstable branch and we try to release a few new snapshots over the course of each year. For 2014 it will be just this final release. We did a lot of stabilizing work in the past year, besides working on further integrating systemd and working on dev releases. We know it is not ideal to have an install medium that is older than six months, so please accept our apologies for that, we will try to release more often.

All our flavours are in pretty good shape, so we will not waste time with an RC and do the real release right away.

siduction 2014.1 – Indian Summer is shipped with six desktop environments: KDE SC, XFCE, LXDE, LXQt, GNOME and Cinnamon, all in 32- and 64-bit variants. From the included DEs this time around only LXDE fits on a CD with 700 MegaByte. But as CDs become more irrelevant with every day, we are not too worried about this and recommend to use USB-Sticks for installation.

The released images are a snapshot of Debian unstable, that also goes by the name of Sid, from 2014-11-22. They are enhanced with some useful packages and scripts, our own installer and a custom patched version of the linux-kernel 3.17, accompanied by X-Server 1.16.1.

Besides those desktop environments we also include noX, which is an environment without X. There is, last, but not least, an image that listens to the name of Xorg and it features the minimal window manager Fluxbox on top of X.

A year ago we decided to release with systemd, while Debian was still discussing, what init system to use in the future. Meanwhile Debian and Ubuntu have decided to go with systemd as well. It is the most technicaly advanced of the init systems at hand. We have a preliminary section on systemd in our sidu-manual, which will be expanded and translated to other languages.

What is new?Cinnamon
After our dev release of Cinnamon in October was well received, we are shipping Cinnamon as a full member of the siduction flavour family. For further information on the innards of this GTK+ 3 driven desktop environment, please refer to the release notes of that release.

We gain two, we loose one. Razor-Qt is not released by us anymore as it is at it’s end of life and merged into LXQt, which we have the pleasure to talk about now, because that is the 2nd addition to our family. With our developer agaida being upstream of LXQt, we will always have the very latest functional packages in our repositories. LXQt has matured a lot and deserves to be part of the family. Even though it has not yet reached the polished swiftness of LXDE, it is on a good way. It has been completely built on Qt 5 and is in large parts prepared for Wayland.

And besides that?KDE SC
KDE SC has matured to version 4.14.2, which is one of the last iterations of the KDE 4 chapter. We have taken Kickoff menu out and implemented Homerun instead. Systemsettings has two new modules that debian does (not yet) have. One of them is called ‘Desktop Search Advanced and is a more detailed configuration module for Baloo, the successor of Nepomuk. Also, as a second search agent for Baloo besides Dolphin we have integrated Milou into the panel. The other new module in systemsettings is labeled Systemd and ships a plethora of options that can be of tremendous help with configuring the systemd daemon.

You can safely assume this is the last siduction release shipping software from KDE’s fourth cycle. Our next release will ship Frameworks 5 and Plasma 5.

GNOME
GNOME shipped version is 3.14.1 and it brings new things. As GNOME is still pretty new in our release cycle, here is a few hints on how to run it:

There are two ways to start your gnome-session:
* GNOME-Classic, which implements the GNOME2 look
* GNOME, which implements the GNOME 3 look and desktop-effects
To choose GNOME or GNOME-CLASSIC users should choose default session from the display manager menu. By default in live mode GNOME 3 is started but it will use software rendering. To use GNOME 3 with hardware rendering, users of ATI cards must install firmware-linux-nonfree before starting the installer. Boot cheatcode “gnome” was removed because it is now deprecated. Windows look in GNOME has changed because GNOME developers dropped minimize and maximize buttons. To minimize or maximize a window, you must use right click in the window title bar and choose minimize or maximize from the menu. Also, to maximize a window you can double click on the window title bar. We have added to Favourites Applications (aka Dash) some of most used applications. You will discover hexchat, transmission, libreoffice, siduction bug report tool, gnome-terminal and many more in Favourites Applications.

We ship noX, for the second time around, as an official release, which was first introduced in October 2012 as development release. As there is no graphical environment, you need to use cli-installer as root to run the installation.

XFCE is still being shipped in version 4.10.1 and is as reliable as ever. It is a desktop environment that just gets out of your way when work needs to be done.

Next to LXQt we also ship the latest version of LXDE, which is also lightweight, but relies on GTK+ 2 instead of Qt. LXDE will be developed as long as GTK+ 2 stays usable.

A lot of time consuming changes again went into adapting the codebase we forked to our needs and integration of systemd. Work on the sidu-manual, as it is called now, is ongoing to make it a lot easier to add new content than before.

The installer offers btrfs still as an experimental filesystem. Please be careful if you use it and always backup your data. Also, the installer for now has been reduced to it’s basic features until more sophisticated stuff works more reliably. Due to some internal changes in fdisk some parts of the automatic partitioning have to be rewritten. as there was not enough time, we took that feature out for now.

We had to make some changes to the concept of our artwork. We used to devote each release to a rock song and try to have a matching artwork. For two reasons we gave up on that idea. For one, for a while this year we had no art team at all. On the other hand it takes quite some time to integrate artwork into the infrastructure in it’s respective places and make it all work. With the new concept things became a bit easier, all we basicaly need to do is alter the colours or patterns of the given artwork. The distro-art we are using for this and the following releases for the forseeable future was created by Bob, a professional artist. Thanks a lot for your contribution!

Support can be obtained on our forum as well as on IRC. The relevant channels on OFTC-Network are #siduction for english support or #siduction-core, ifyou like to join in and participate. On your desktop you also find an icon that takesyou to the right channel for support, depending on the chosen language.

To be able to act as a testbed for Debian, we are introducing our own bug-tracker. Let me explain how you can help us and Debian by submitting bugreports for broken packages. Weathered users will know how to file bugs directly with the Debian BTS (Bug Tracking System). For users not so comfortable with the system we have reportbug-ng preinstalled.

If you think, you found a bug in a Debian package, please start reportbug-ng and put the name of the package in the adressline ontop. The app will now search through the already filed bugs for that package and show those. Now it’s up to you to determine, if “your” bug has already been reported. Ifit is, ask yourself if you have anything relevant to add to this report or maybe even a patch. If not, you are done for this time. If the bug has not been reported yet and you are not familiar with the BTS yet, you may report the bug in our Bug-Tracker.

That obviously goes for siduction packages as well. We will sort the bugs for you and file them in the appropriate place, if it’s reproducible. Please look out for a forum post with more detailed info on the bug-tracker soon. If all this seems to complicated for now, feel free to use the bugs-thread on the forum for now, it will keep working until final release.

There is nothing we can tell you about our release cycle other than that we strive for up to four releases per year, but that may vary greatly, depending on developement of siduction and Debian Unstable.

As we are always looking for contributors, here is what to do: Come to IRC to channel #siduction-core and talk to us about what you would like to do within the project, or where you think you could help. As you will notice if you scroll down, we have no art-team at the moment. If you are willing and capable, talk to us.
Hardware Tips

If you should own a ATI Radeon graphics accelerator, please use the failsafe option, when booting the Live-ISO. This option will add the cheatcodes radeon.modeset=0 xmodule=vesa to the Kernel bootline, so that you can boot to X. Before installing, on the Live-ISO, please install firmware-linux-nonfree. To do so, please open your /etc/apt/sources.list.d/debian.list with your favourite editor as root and append contrib non-free to the end of the firstline. Save the edit and do:

apt-get update && apt-get install firmware-linux-nonfree

If you install the operating system now, the package will be installed also, preventing you from a garbled screen when first rebooting. Mind that if you reboot before installing the system, the changes you made will be lost.

If your system has wireless network, this will probably not work out of the box with free drivers, so you better start with wired network connected. You might want to use the script fw-detect to get information on wireless drivers. The installer will prompt you for any missing firmware and guide you through the process of installing it.

Last but not least a hint for users of the kernel based virtual machine KVM. The developement of a frontend for the kernel based virtual machine (kvm) has begun as a fork of qemu with the name qemu-kvm or short “kvm”. Since qemu version 1.4 all patches of the kvm fork have been integrated back into the qemu source. Also there has been much progress in the field of virtualization. So there is a lot of outdated documentation around. We have a current worksheet for Qemu in our wiki.

The ‘Init Wars’ around systemd are still not over yet, unfortunatly. New flames rose from the ambers on the weekend when Ian Jackson revisited a proposal for a GR (General Resolution) that had died away in March when first proposed because it could not even muster 5 supporters. Under the flag of ‘Preserve freedom of choice of init-systems’ he tries to abandon “coupling” and “loose coupling” of the package providing PID 1 with other packages if not strictly necessary. That is all fine and dandy, but who does the work? You cannot make upstream or package maintainers do work they don’t want to do. Besides that I have not forgotten Jacksons role in the decision making on a new init system for Jessie within the Technical Comitee (CTTE) in February. So one could suspect, Jackson wants more than he is telling us.

Just two days later – what a coincidence – another initiative jumps the bandwagon, threatening to fork debian, should systemd stay the default for Jessie. They describe themselves as “Veteran Unix Admins” that want to control init “with shell scripts that are readable, because readability grants a certain level of power and consciousness for those among us who are literate” Now c’mon, that must be a joke, right? No, they seem to be serious! Did you ever compare init scripts with systemd’s service files? Then you should know better. I also can’t honestly imagine that a lot of weathered system admins would choose sysvinit over systemd. The ones that I know, prefer systemd but do not talk about it because they have work to do.

The approach of this anonymous group – their website is on a private domain – shares something with most of the systemd boycotters: lack of technical arguments that will stand longer than a minute in a open discussion with open minded people. What we do find is a lot of FUD like “The current leadership of the project [debian] is heavily influenced by GNOME developers and too much inclined to consider desktop needs as crucial to the project, despite the fact that the majority of Debian users are tech-savvy system administrators.”

My take on the whole init war is that it is solely a social phenomenon. We tend to stick to what we are used to and have a hard time accepting new ways of doing things, even if they are superiour. We religiously want to stick to the UNIX philosophy because it kept us warm and dry for the last 30 years. But sometimes a deeper cut is needed to move on and not be stuck with the inferior, even though it served us well for many a year.

And please do not believe the systemd-trolls, they are not telling you the truth. Debian jessie has perfect freedom of choice. It has an essential meta-package “init“, which requires (and allows) you to install either systemd-sysv, sysvinit-core or upstart. So that means more freedom of choice than before!

That being said, a fork of debian that would truly justify the name would be a huge effort, made up of hard work instead of big words. But other than uselessd words are all we got so far. So my take on this is that the threat of forking debian is quite a blunt weapon. And for the ones who like their popcorn served with a flame war: Wayland vs Xorg lies ahead 🙂

We are very happy to present to you today the first integration of the cinnamon desktop environment into siduction. Cinnamon is a modern desktop based on GTK 3 with a classic look. It has been developed and published by the popular Linux Mint distribution since 2011. Recently Cinnamon version 2.2 has made it into Jessie, Debians upcoming release. A team of several Debian developers has worked on the packaging for about three monthsand has matured the whole set of packages. We can expect it to be functional.

Almost three years ago I wrote a lengthy article on how to align, partition, configure and benchmark Solid State Disks under Linux. Those were the early days of these NAND flash memory devices and you had to jump through some hoops to get them to perform at their best when it comes to performance and durability. So by now parts of the tutorial have been obsolete for some time now. Graphical partitioning tools e.g. handle the alignment of these devices correctly nowadays, which they did not do back then. I have never found the time to go back to that article and bring it up to the latest.

So we are grateful, that Don, who on the forum goes as dibl, took it upon him to present us with a modernised version of this tutorial. Not only does he eliminate cruft that is obsolete or plain wrong nowadays, he also describes a different concept of trimming these devices. This method substitutes the discard parameter in your fstab, that takes care of the trimming for most of us. This method makes use of the fstrim command from the package util-linux, which, which is run, preferably when you are absent from the machine, by a script using cron on a daily or weekly turn. This prevents that discard calls TRIM every time we delete a file and slow things down. So, here we go, thanks again, Don.

Optimizing SSD-based System Performance

The goal of these configuration settings, generally, is to select and configure a suitable filesystem, to minimize erase/write cycles that don’t add to system performance, to enable TRIM, and otherwise to optimize the OS to provide a very responsive user experience.

1. Filesystem type and /etc/fstab configuration

We want to use ext4 and take advantage of the journaling feature, for data security, but we want to reduce the frequency of journal commits (writes to the SSD) from the default 5 seconds to a slower rate, to extend the life of the SSD memory blocks. The “commit” mount option controls the frequency of journal commits, and as mentioned is set to 5 seconds by default. Understanding that slowing down this frequency also raises the risk of data lost in a power loss or system freeze situation, choose a slower frequency that you are comfortable with, like “120” for two minutes, a reduction of 24x. To avoid writes caused only by reading files, use the “noatime” option. As a result, the /etc/fstab line that mounts the OS will look like this:

For typical laptop and single-user computers, we want to mount selected filesystems as “tmpfs”, which lets the OS use memory rather than the SSD for logging and spooling. The wise user will wait for a reasonable period of time after initially installing on the SSD, before these changes are made to /etc/fstab, because until you are sure your system is stable, you should allow the logs to be written on the SSD, for later review. Logs written in memory will not survive a reboot. When you are satisfied that the system is stable and the logs can safely be lost at each reboot, add these lines to the end of /etc/fstab:

Alternatively, you could mount these directories on a hard disk drive if one is also installed in the system – a better approach for a server, for example, where you might need to periodically review older logs.

2. Enable TRIM

Recent guidance [4] recommends using the fstrim utility periodically, rather than using the “discard” filesystem mount option. At the conclusion of the linked blog, a very handy script for use as a cron job is shown, and it is repeated here for convenience:

Note that LVM systems and LUKS/dm encrypted filesystems add additional configuration tasks to the basic filesystem configuration described here – follow the guidance to enable TRIM at each level of your system configuration.

3. Outsource the browser cache to /run/user (guidance for single-user system, can be expanded for multi-user implementation)

Since Debian now has the shared directory /run/user/usernumber in RAM, we can outsource the cache generated during browsing to memory, and eliminate many SSD writes. For example, in the Firefox/Iceweasel address bar we enter “about:config” and confirm the warning. Now right-click in the white space and choose “New ==> String” and we create a new entry called:

browser.cache.disk.parent_directory

After double-clicking the new string, we assign it the value:

/run/user/1000/firefox-cache for the first user.

Now as user in the terminal create a directory:

mkdir -p /run/user/1000/firefox-cache

After a Firefox restart, browser caching happens in memory, not on the SSD.

For chromium-browser, the cache location is set with the --disk-cache-dir=”DIRNAME launch command option. So to outsource the chromium-browser cache:

mkdir -p /run/user/1000/chromium-cache

Open the chromium-browser launch icon for editing, change to the »Application« tab, and edit the start command to read as follows:

Note that this will need to be done again after each chromium package update overwrites it.

The new browser cache directory in /run/user will not survive a reboot. To automate this process, put the following “auto_browser_cache.sh” script in your ~.kde/Autostart folder (for KDE users), and then chmod +x to make it executable:

Analogous cache outsourcing configuration can be made for other browsers, if they allow the user to specify the cache location, and the startup script can be adapted to add directories for each browser that the user wants to run.

For a desktop system that remains booted for long periods, and depending on the memory capacity and browsing activities, the outsourced browsing cache could grow to a problematic size and need to be manually cleared to avoid sending the system into swapping.

4. I/O Scheduler selection

Multiple sources that you can find with a google search indicate that, for SSDs, the “deadline” and “noop” schedulers perform better than the default “cfq” scheduler, with deadline getting the most recommendations. Set the scheduler in /etc/sysfs.conf as so:

block/sda/queue/scheduler=deadline

5. Virtual memory settings

Depending on how much memory your system has, and how you use it, the same tweaks to vm (swappiness, vfs_cache_pressure, etc.) that you use for a hard disk drive installation can also be applied to a system installed on a SSD. Guidance is available via google search as well as the two excellent references below. Here are the lines added to /etc/sysctl.d/sysctl.conf on one of my SSD installations:

Before you spend time on performance testing and benchmarking your SSD, you need to determine the firmware version you have, and then check the OEM’s website and learn whether a more recent version is available. Significant performance improvements can result merely from updating your SSD firmware — follow your OEM’s instruction to install updated firmware. To check your firmware version:

hdparm -iv /dev/sdx

6. Verify that TRIM is working (after setting the “discard” mount option as shown in #1 above).

# cd to some directory on the SSD, thendd if = /dev/urandom of=tempfile bs=512k count=100 oflag=direct
hdparm - fibmap tempfile
# here we read the sectors from the tempfile

From the output we copy the number immediately under “begin_LBA” and insert it in the next command:hdparm - read-sector 1234567 /dev/sdx
# 1234567 replaced with the number from the previous command and /dev/sdx with your device ID

The sectors will not be cleared instantly due to caching — wait for some seconds. Then repeat the last command (hdparm – read-sector …) — it should (after a short while) come out all zeros. That means TRIM works! If you have problems with “discard” on your SSD and you have verified that your SSD does support TRIM, you can use fstrim which is in the current util-linux package (check “man fstrim”), or use the tool “DiskTrim” from http://disktrim.sourceforge.net/.

7. Throughput Benchmarking

CAUTION: You can benchmark your SSD to a premature death by subjecting it to frequent comprehensive benchmark tests!

7a. Simple hdparm test:

hdparm -tT /dev/sdx

Run it twice in rapid succession — normally the second run is fastest.

The temperatures are dropping, outside your window and even more so within Debian. In less than a month Debian will go into hibernation to prepare for the next stable release Debian 8 »Jessie«. The upcoming freeze leads, even more so than with other Debian releases I remember, to a flurry amongst the developers. Everybody tries to get their latest developements into sid to have a chance to see them integrated in Jessie in a couple of months.

That being said, me abstaining from this blog for a while due to time restraints does not mean, your favourite distribution is not moving forwards. Everyone watching our git repositories will know we are constantly busy improving what we already have. So what have we been doing? Besides working on a better integration of systemd into our build tools we are concentrating on two releases: for one, 2014.1 has still not materialized, even though a lot of work has already been devoted to it.

The reason for that is that at this moment, there is only one desktop environment that could undoubtedly be released as is and that is XFCE. This is due to the fact that there has been no major updates for quite some time now. On a close second rank is KDE SC, which is, despite the upcoming switch to it’s fifth iteration, in pretty good shape. Gnome has just been updating (or is still in the process of doing so) to 3.14, with some glitches to be ironed out still.

Then there is the LXDE/LXQT/Razor-Qt conglomerate. As you will know, LXDE and Razor-Qt are going together under the Qt framework to form a new desktop environment. Razor-Qt will not be released by us anymore, it is practicaly dead, while LXQT is not quite where it needs to be for a release. As LXQT 0.8 is still not released (a 0.8rc1 might be due these days), LXQT unfortunately will not make it into Jessie. We will for sure let you try out a dev-release once LXQT is worthy of it.

Another desktop environment that will definitely make it it into debian’s next release is cinnamon. And that is the second relesase I told you we were working on. Before sicution 2014.1, in a matter of days, we will bring to you a dev-release of siduction cinnamon. Longtime supporter musca has commited himself to bring cinnamon into shape for siduction and I can tell you that a lot of love went into this project. So soon you will see a rather polished dev-release bringing the cinnamon desktop to siduction. You now may hold your breath.