An interview with the EDE developer

It’s summer solstice today and thus the longest day of the year. I promised something special and here it is: Sanel Zukan, the man behind the Equinox Desktop Environment (EDE) agreed to give me an interview (or to answer a few questions if you will).

If you’re not familiar with EDE, I tried to summarize it up for you before the interview.

EDE in short

What is EDE? It is a full DE you might not even have heard of despite it being one of the older *nix desktop environments. Of course it’s older than Unity, MATE, Razor-qt and the likes. But it is also older than LXDE and – hard to believe – E17! At the same time it’s more light-weight than any of these – including the ones which were created as light-weight alternatives themselves.

Said DE is something special. Where others talk about being light-weight, EDE seriously means it and takes the gloves off. Not making any compromise, it’s the only full DE which is based on FLTK (Fast Light Toolkit), a GUI toolkit which also lives up to its name.

Not being packaged by any major distribution, today EDE is mainly used on older pcs or other systems which are low on resources. It doesn’t provide its own applications for everything nor does it want to. Driven forward more or less by one lone fighter, it surely doesn’t have to hide and fear comparison with other DEs. Taunted as “poor man’s KDE” by some and appreciated as an insider’s tip without all the knick-knack by others it’s just going its way. And if it rightfully deserves one label that would be “No bloat here”. Seriously.

Interview with Sanel Zukan

The following interview was conducted by email.

Please introduce yourself first: Who are you, how old are you and where are you from?

I’m 32, from Sarajevo. By day I’m doing java/python stuff for a small local company and by night I try to hack various OSS projects; of course EDE, too.

Do you have any special interests aside the IT sector you would like to mention here?

Martial arts! ๐Ÿ™‚ It is quite challenging to combine IT work with regular training …

For how long have you been using Linux?

Let’s see… For approximately 10 years.

Which is your distribution of choice and why?

Slackware. Because it is simple, lean and very, very stable. I really admire Patrick (Slackware author and maintainer) because he is showing us how a complex project can be and should be maintained.

Is there anything in the Linux or FOSS world you are not really happy with?

The idea to reinvent the wheel all over again. PulseAudio, systemd, gdbus, kdbus, *Kit, are some examples. Instead of improving the current state, those guys focus on rewriting it, making another set of mistakes which brings the full idea back to the beginning: a half balked product.

Also this is quite hard to follow from a developer’s perspective because APIs are changing often; no wonder that developers are going to OS X or *BSD land. This whole way of thinking makes Linux look bad, especially from a novice user’s perspective.

There are more than 15 desktop environments in use in the Linux world. Why did you decide to dedicate your time to EDE?

I like fast, simple and responsive environments without much of bloat that don’t get in your way. Desktops should be invisible and the user should be able to focus on daily tasks more than on desktop effects.

And I like to revive old computers: they are still usable for daily tasks so why to throw them away? Now, the last thing on those computers you want is a desktop that eats all of your memory or cpu power.

What can you tell us about early EDE?

Not much because I’m not familiar with its early history. When I came in, the project was pretty much dead and all original developers had left it. Not sure about the reasons because I never got any reply from them.

What do you think were the most remarkable achievements of versions 1.x?

The project gained some traction and people started to talk about it. One of the reasons for this were regular releases (5-6 months).

Most developers retired from working on EDE. Can you tell us the reason for that? Was it due to technical problems? Real-life issues? Or perhaps the fact that EDE never became popular and remained an underdog to this day?

Maybe a little bit of everything. Working on a desktop isn’t an easy task because there are a lot of pieces involved in it: UI development, low-level stuff, application incompatibilities, etc. Also, doing it in your free time requires dedication.

Do you still have contact with the retired devs and do you know if they still care for EDE (though not actively participating)?

Only with Vedran. Others (except Dejan) never bothered to even reply to my mails.

You took over EDE – and managed to rebuild the DE from scratch with version 2.0. Why did you continue to work on it and did anybody help you? Where did you draw your motivation from?

Sure, there are a lot of people who come and go, give some ideas, fix issues; this project would not be alive without their help that’s for sure. Why do I continue to work on it? Because there is no desktop that satisfies my needs: be simple and stable. And it is fun.

“eFLTK” – can you tell us what that was and why it was created?

eFLTK was a fork of the never-released FLTK 2.0 and it was created with the idea to speed up FLTK 2.0 development and make desktop development easier.

FLTK, following true UNIX philosophy, is a GUI only toolkit and you need much more for a functional desktop environment. That is the main reason I still prefer FLTK over other popular GUI libraries; I’m paying only for what I use.

This modified toolkit was one of the main reasons to start over with 2.0, right?

Yes. Maintaining a desktop and a complex toolkit (eFLTK got a tons of new stuff) isn’t an easy task so we decided to drop it and go on using something with much better support.

Why are you using FLTK? Why not for example FOX (which has its own desktop project that however seems to go nowhere)?

Probably by accident. ๐Ÿ™‚ When I started to use and develop for Linux, I didn’t have much experience with UI development, so I searched for something that is easy to pick up, small enough to grasp and have good OpenGL support.

I needed OpenGL because, in that time, I tried to build some level design tool for my pet game.

According to their site, LXDE considered using FLTK as well. In the end it was rejected in favour of GTK+ because it offered too little internationalization support. What about EDE in this regard?

One of the main reasons why we pushed eFLTK for so long is because FLTK 1.1.x, in that time, didn’t have UTF-8 support, which is probably the reason why the LXDE guys ditched it.

Do you use EDE on a daily basis? What other DEs do you like?

Yes. I’m using it on all my computers, including on work; that is why I’m focused on stability so much. It is not good idea to lose all of your daily work because of a bug in the WM or panel.

Other DEs I like? I like ร‰toilรฉ (http://etoileos.com) because they are doing some really cool stuff; I’m not sure what the current status is because the project looks dead to me, which is quite sad.

Those who followed the development of EDE mostly thought that the project was dead when all of a sudden 2.0 final was released. What had happened?

We (Vedran and I) went silent to focus on 2.0 development and release it as soon as possible. It took some time because there was a lot of work to do, and we did it twice!

To explain this, I need to tell some of FLTK’s history which greatly affected EDE. FLTK project had two main branches, stable 1.1.x and 2.0.

FLTK 2.0 promised a lot of new and shiny things, like namespace support, UTF-8, advanced X stuff (RandR, Render and etc.). EDE initially started to use FLTK 2.0 (even before I joined) which was forked at some point and eFLTK created.

After some talk with the FLTK 2.0 devs, they promised us to make a release soon; we ditched eFLTK, started to rewrite EDE in FLTK 2.0 and started to contribute to that toolkit.

Unfortunately that library (as if it was cursed) never got released. I got really mad and rewrote everything (with Vedran’s help) again in FLTK 1.1.x and never regretted it. This should have been done long time ago.

Are you happy with 2.0 in general?

Pretty much.

What about EDE users – do you get a lot of feedback? Are there any features which are often asked for?

Yes; I’m getting more feedback by mail than on the EDE forum, which isn’t good as people new to the project tend to think it is inactive. However, I understand why people sent me the mails: SourceForge forums are extremely bad and they get a reply much faster. ๐Ÿ™‚

Main features asked for are more configuration support, a file manager and support for internationalization. Funny thing: no one ever asked for compositing or blinky blinky stuff.

EDE 2.1 is on its way and might be available soon. What new features can EDE users expect from it?

More stability, more speed and tons of little improvements including full panel configuration.

Let’s talk about the future. What are your plans for EDE after 2.1? What is your “goal” with EDE?

Truth to be told, after the 2.0 rewrite I learned not to do any big changes anymore but small incremental ones instead. So after 2.1 I’m planning to add a File Manager, fix remaining bugs and add more DBus support.

Ultimate goal? I really like and admire Smalltalk environments (like Pharo) where you can change, adapt or remove programmatically any part of it. I would like to add some of those things in EDE but it will be quite challenging, because Pharo is powered by Smalltalk and EDE is done in C++ which isn’t suited for runtime dynamism. That is why I added a Scheme interpreter and plan to use it more often in the future.

A little statistics: How many daily hits does the project homepage currently have in average?

Huh not sure; the last time I checked EDE had ~5000 hits per hour; now if half of that are bots, the stats aren’t bad considering the last release was a year ago and the project isn’t mentioned much in the media.

However, there are very big peeks each time a new version is released.

What do you think are the reasons for EDE to be still quite unknown among Linux users despite existing for more than 10 years? How to change this fact?

Probably a few things:

1) lack of frequent, predictable releases
2) more advertizing
3) support from a big company

If you remember, LXDE gained wide traction when RedHat created a Fedora spin for LXDE.

There’s also the FLTK applications project – but it hasn’t really released anything, yet. Do you know anything about that or about any FLTK applications in the making?

Not much. It was probably some attempt to document and collect popular applications, but never got significant traction. Probably one of the reasons is that more people develop commercial applications with FLTK, because it still has a quite liberal license.

You awake at night, a strange light surrounding you. The good FOSS fairy is floating in the air before you! She can do absolutely everything FOSS related; whether it’s doxygen with zero dependencies, FLTK 2 revived and actively developed or something a little less unlikely. ๐Ÿ˜‰ She grants you three wishes!

LOL. Well:

1) Live kernel update
2) File system with good snapshot and history support (like ZFS)
3) Webkit with FLTK backend

Ok, back to serious. A coder with some time on his hands is searching for a new project. He stumbles over EDE and likes it. If he asked you how he could help with it what would you advice him to do?

He could try to fix things he don’t like or create applications he would like to see. I’m always open to ideas and ready to give some guidance.

Which FLTK application that was never made do you miss the most?

Webkit with an FLTK backend. There was some project a long time ago including even a screenshot, but author never made any code public.

Why was EDE’s own WM replaced with PekWM? What are your plans for the future of the WM used in EDE?

To speed up the release. Developing a WM from the scrach, or porting it to another toolkit, is quite time-consuming so I used pekwm as temporal replacement. There are plans to replace it, but I’m not thinking about it right now, because there are more important things to be done, like the file manager.

Thanks a lot for taking the time to answer these questions – and of course for EDE! I wish you success with your further work on it.

What’s next?

My next blog entry will be about EERIE turning 1 year old and about what has been accomplished so far.

Situation of the Linux Desktop #2: Habemus tumultum…

… qui nomen nominatur “pacem”!

Wow, Latin! Oh er, welcome back! Wonder what that strange sentence does there – and what it may have to do with the Linux Desktop? Well, due to unforeseeable incidents when moving houses along with some family matters, I was more or less cut off from any news. I didn’t have internet connection for about one month and was not in the mood to buy a newspaper (and since TV and radio programs are more or less useless to disgusting and a total waste of time, I don’t own a TV or a radio). You can probably imagine how surprised and amazed I was yesterday when I finally read what had happened in the meantime!

The news of not even a handful of weeks missed – and all of a sudden the Roman Catholic church has a new pope (even though the old one didn’t die!). That was what inspired my headline which translates (or at least should translate) to: “We have a turmoil… which is called (the name) peace!”

“ะœะธั€”

“Peace”?! Yes, peace. It’s one possible translation of the Russian word in the sub-headline above. Others are “world” or even “universe”, but I couldn’t resist to put together peace and turmoil. ๐Ÿ˜‰ What the heck am I talking about? Alright, alright. You’ll know what I mean right away. “ะœะธั€” is pronounced… Mir!

Well, Mir! You’ve probably heard of the new display server which Canonical (makers of Ubuntu) announced. Even this announcement had a huge impact in the Linux world. A lot has already been written about it. But this is one topic that clearly affects the subject of my blog – the Linux Desktop. While I tried not to be too biased about Ubuntu in the past, Canonical are giving me a hard time once again.

Closed graphic drivers

My position on the efforts of Canonical, Valve and others was one of cautious confidence that it could be of great value to the Linux community. I’m not one of those Linux fans who want this operating system to “succeed” and I don’t really care for market shares and things like that. But there’s certainly some truth to the fact that we’d all benefit from good drivers provided by the companies who build the hardware. Yes, while I prefer open drivers (for obvious reasons), I don’t have a problem with closed drivers being available, too. It’s one additional option for those who need the performance, reliability, etc.

It’s common knowledge that X11 is really old now and that this is not just beginning to show. For the conservative desktop environment X will remain the display server of choice but the general next step, the future of the modern Linux Desktop would be Wayland. Almost everybody agreed with that – at least until early march. A few years ago even Canonical had praised Wayland and planed migrating to it in the future. Now said Company is developing their own display server Mir…

Canonical’s Mir and Wayland

Alright, Canonical have abandoned the classic desktop with Unity and are clearly aiming for the mobile market. That’s ok, I guess. But developing a new display server and convincing Nvidia (who already hesitated to support Wayland!) to support it instead of Wayland is not a nice move at all. Doing so at this particular time (before Wayland could actually play any role) really looks like an attempt at backstabbing that other display server for me!

Thanks to Canonical, Nvidia will be even less motivated to offer drivers compatible with Wayland. Canonical’s founder even boasted of Mir possibly running on more devices than Wayland! That sounds like a plan. A plan that may be very profitable for Canonical but also a plan that can prove to be devastating for the Linux community. How to treat the new situation? Curse and boycott Mir? That’s probably overreacting. Embrace and praise Mir? Certainly not at this time. Anyway all this is a development that we should eye closely. Perhaps Mir will provide a few interesting features in the future. Right now it’s just a concept – and a splitting one. Let’s see what happens next.

GNOME 3 and Consorts

Another thing has happened since I wrote the first “Situation of the Linux desktop” in November. MATE is no longer the only promising GNOME fork. Now there’s also Consort.

The difference between them is that MATE picked up the dead GNOME 2 and remains based on the GTK+2 toolkit. According to the makers of Consort, this is “dead technology” and their effort is maintaining a classic GNOME desktop based on GTK+3. GNOME 3 will be dropping their “GNOME classic” or “fallback” mode with the upcoming version 3.8. This mode resembles GNOME 2 in many ways – but the most important thing for many people is the fact that it does not require hardware graphics acceleration. So Consort will be picking up where GNOME 3 Classic left.

Currently Consort doesn’t work with Arch Linux so I didn’t test it, yet. So I can’t say much more about it right now.

The situation!

The Linux Desktop has fragmented even more since my last post. With Consort there’s a new desktop environment in preparation and with Mir there’s even a new display server in the making. The later could even be seen as a hostile attempt to sabotage Wayland. More than ever the situation is getting unclear and confusing. Probably a good time to work on the DDD again?

What’s next?

Next I’d like to release a new version of the DesktopDemoDVD.

Qt-based applications #3: Text Editors (2/2)

The last blog entry was about a test of 9 Qt-based text editors (those which I could get to run on Arch Linux). And since the comparison of so many programs and values is not really an easy thing, here’s a second post providing some tables which show the programs sorted not by name but by values.

Overall ranking

Here’s the table with the overall results. The text editors were compared in terms of 1. memory consumption (most important for me and thus weighted *3), 2. disk space used (weighted *2) and 3. size of packages to download:

Rank Text editor Version
01 Minerva GIT20130220
02 CuteNotes 0.9
03 TEA editor 34.0.1
04 Catlooking Writer 1.0
05 JuffEd 0.8.1
06 FocusWriter 1.4.1
07 KoalaWriter 1.0
08 Marave 0.7
09 kWrite 4.10

RAM usage

Here’s the table comparing memory use:

<10 MB 10 – 25 MB 26 – 50 MB > 50 MB
Rank Text editor Version
01 Minerva GIT20130220 4 MB
02 TEA editor 34.0.1 6 MB
03 Cutenotes 0.9 8 MB
03 JuffEd 0.8.1 8 MB
04 Catlooking Writer 1.0 15 MB
05 FocusWriter 1.4.1 26 MB
06 KoalaWriter 1.0 36 MB
07 kWrite 4.10 64 MB
08 Marave 0.7 78 MB

Drive space needed

Here’s the drive space table:

<20 MB 20 – 100 MB 101 – 200 MB > 200 MB
Rank Text editor Version Disk space used
01 Cutenotes 0.9 +1 MB
02 Catlooking Writer 1.0 +2 MB
03 Minerva GIT20130220 +5 MB
04 TEA editor 34.0.1 +6 MB
05 JuffEd 0.8.1 +7 MB
06 FocusWriter 1.4.1 +9 MB
07 Marave 0.7 +154 MB
08 KoalaWriter 1.0 +363 MB
09 kWrite 4.10 +582 MB

Download size

And the download size table:

<1 MB 1 – 10 MB 11 – 50 MB >50 MB
Rank Text editor Version size
01 CuteNotes 0.9 +143 KB
02 Minerva GIT20130220 +319 KB
03 JuffEd 0.8.1 +973 KB
04 Catlooking Writer 1.0 +1.2 MB
04 TEA editor 34.0.1 +1.2 MB
05 FocusWriter 1.4.1 +2,4 MB
06 Marave 0.7 +24 MB
07 KoalaWriter 1.0 +77 MB
08 kWrite 4.10 +126 MB

Conclusion

When it comes to Qt-based text editors, we can see huge differences between them. With Minerva there’s an editor that really deserves the MIN in its name: It does good in all aspects and is the winner in this test. Rank 4 for the Catlooking Writer shows that even those non-distracting writers don’t necessarily have to be extremely resource-hungry. And well, no surprise: kWrite scores the last rank since it depends on the super-heavy kdelibs.

What’s next?

Next I’d like to pick up the DDD again and create a new version. Then I’ll examine the basic GTK+ applications.

This post was written on 02/27 and automatically published. If I didn’t remove that line that means that I still don’t have a working internet connection.

Qt-based applications #3: Text Editors (1/2)

In this post we’ll take a look at some Qt-based text editors. Just like with the file managers I’ll split my post in two parts because there’s quite a number (I found 15!) of such editors out there.

While compiling my list of Qt-based editors, I came across something I hadn’t heard of before. A kind of application which is called non-distracting writer. At first I wasn’t sure whether to include these here, but they don’t fit into the category “Office application” either.
From my point of view they are close enough to text editors to include them here (they are written with the idea that the text is the only thing really important – and that’s pretty much what qualifies them as a text editor, though not a classical one).

The candidates

Here are the text editors that were tested (in alphabetical order):

Not tested

Many of the editors didn’t work right away. I got some of them to work in the end, but these are the ones that wouldn’t work at all and thus were not tested:

If anybody can get one or more of these to work on Arch, please let me know (send me PKGBUILDs?). And also tell me if you think that I forgot anything interesting!

Testing system

For this test I’ve set up the VMs as in my first Qt application test + Virtualbox guest additions this time. Here are the new values:

Arch Linux + Razor-qt (0.5.1)
MemTotal: 4052828 kb
MemFree: 3810544 kb
Buffers: 9972 kb
Cached: 80280 kb
Rootfs: 936560 / 915
RAM used at startup: 242284 / ~237 MB

Catlooking Writer

The Catlooking Writer is a non-distracting writer based on Qt. It’s a full-screen application that’s intended to let you focus on the text only.

Razor-qt with Catlooking Writer

Installation

pacman -U catlooking-git-20130217-1-x86_64.pkg.tar.xz (1222156 Bytes / 1,2 MB)

Statistics

Memory usage after starting up Razor-qt and opening Catlooking Writer via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ Catlooking Writer 1.0
MemTotal: 4052828 kb
MemFree: 3795300 kb
Buffers: 9992 kb
Cached: 87616 kb
Rootfs: 938696 / 917M
RAM used at startup: 15244 / ~15 MB
Disk space (less razor system): 2136 / ~2 MB

CuteNotes

CuteNotes is a simple text editor based on Qt.

Razor-qt with CuteNotes

Installation

pacman -U cutenotes-1.0-1-x86_64.pkg.tar.xz (142740 Bytes / 142,7 kB)

Statistics

Memory usage after starting up Razor-qt and opening CuteNotes via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ CuteNotes 0.9
MemTotal: 4052828 kb
MemFree: 3802112 kb
Buffers: 9988 kb
Cached: 82472 kb
Rootfs: 937596 / 916M
RAM used at startup: 8432 / ~8 MB
Disk space (less razor system): 1036 / ~1 MB

FocusWriter

FocusWriter is a full-screen, non-disctracting text editor based on Qt. It offers basic support for formats like RTF and ODT, too.

Razor-qt with FocusWriter

Installation

pacman -U focuswriter-1.4.1-1-x86_64.pkg.tar.xz (721800 Bytes / 721,8 kB)
(other packages downloaded as dependencies: 1720320 Bytes / 1,7 MB)

Statistics

Memory usage after starting up Razor-qt and opening FocusWriter via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ FocusWriter 1.4.1
MemTotal: 4052828 kb
MemFree: 3784348 kb
Buffers: 10472 kb
Cached: 89492 kb
Rootfs: 946180 / 925M
RAM used at startup: 26196 / ~26 MB
Disk space (less razor system): 9620 / ~9 MB

JuffEd

JuffEd is a tabbed editor with syntax highlighting based on Qt.

Razor-qt with JuffEd

Installation

pacman -s juffed (972800 Bytes / 972,8 kB)

Statistics

Memory usage after starting up Razor-qt and opening JuffEd via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ JuffEd 0.8.1
MemTotal: 4052828 kb
MemFree: 3801856 kb
Buffers: 10272 kb
Cached: 88012 kb
Rootfs: 943344 / 922M
RAM used at startup: 8688 / ~8 MB
Disk space (less razor system): 6784 / ~7 MB

KoalaWriter

The KoalaWriter is a non-distracting writer based on Qt. It offers beautiful backgrounds and can even play relaxing music so that you can completely stick to what’s actually important: Your text! It’s a bit heavy-weight, though.

Razor-qt with KoalaWriter

Installation

pacman -koalawriter-1.0-1-x86_64.pkg.tar.xz (16714076 Bytes / 16,7 MB)
(other packages downloaded as dependencies: 60160000 Bytes / 60,2 MB)

Statistics

Memory usage after starting up Razor-qt and opening KoalaWriter via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ KoalaWriter 1.0
MemTotal: 4052828 kb
MemFree: 3774164 kb
Buffers: 11544 kb
Cached: 100784 kb
Rootfs: 1308516 / 1.3G
RAM used at startup: 36380 / ~36 MB
Disk space (less razor system): 371956 / ~363 MB

kWrite

kWrite is the default text editor of KDE. It’s quite a bit on the heavy side.

Razor-qt with kWrite

Installation

pacman -S kdebase-kwrite (126095360 Bytes / 126,1 MB)

Statistics

Memory usage after starting up Razor-qt and opening kWrite via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ kWrite 4.10
MemTotal: 4052828 kb
MemFree: 3745412 kb
Buffers: 17548 kb
Cached: 108860 kb
Rootfs: 1532732 / 1.5G
RAM used at startup: 65132 / ~64 MB
Disk space (less razor system): 596172 / ~582 MB

Marave

Marave is a non-distracting writer based on Qt. It’s meant to let the user focus on the text rather than the application.

Razor-qt with Marave

Installation

pacman -U marave-0.7-6-any.pkg.tar.xz (1011384 Bytes / 1,0 MB)
(other packages downloaded as dependencies: 23367680 Bytes / 23,4 MB)

Statistics

Memory usage after starting up Razor-qt and opening Marave via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ Marave 0.7
MemTotal: 4052828 kb
MemFree: 3730568 kb
Buffers: 11232 kb
Cached: 121844 kb
Rootfs: 1093932 / 1.1G
RAM used at startup: 79976 / ~78 MB
Disk space (less razor system): 157372 / ~154 MB

Minerva

Minerva is a tiny tabbed text editor based on Qt.

Razor-qt with Minerva

Installation

pacman -U minerva-git-20130220-1-x86_64.pkg.tar.xz (319276 Bytes / 319,3 kB)

Statistics

Memory usage after starting up Razor-qt and opening Minerva via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ Minerva GIT20130220
MemTotal: 4052828 kb
MemFree: 3806888 kb
Buffers: 9988 kb
Cached: 81580 kb
Rootfs: 942040 / 920M
RAM used at startup: 3656 / ~4 MB
Disk space (less razor system): 5480 / ~5 MB

Tea Editor

The Tea Editor is an advanced editor based on Qt. It offers a lot of features and is still both small in size and frugal in terms of ram usage.

Razor-qt with Tea Editor

Installation

pacman -S tea (1239040 Bytes / 1,2 MB)

Statistics

Memory usage after starting up Razor-qt and opening Tea via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ Tea editor 34.0.1
MemTotal: 4052828 kb
MemFree: 3804856 kb
Buffers: 10172 kb
Cached: 84644 kb
Rootfs: 942756 / 921M
RAM used at startup: 5688 / ~6 MB
Disk space (less razor system): 6196 / ~6 MB

What’s next?

My next post will provide tables which will make it easier to compare the important values of the programs tested here.

Don’t worry if it takes me a while to publish it – I’m moving houses so time is an even more scarce resource than usually and I might be left without a working internet connection for a while.

Qt-based applications #2: File managers (2/2)

In the last blog entry I tested 8 Qt-based file managers (those which I got to run on Arch Linux). Since that’s quite a bit of stuff, I’d like to present a nice table in this post for easier comparison.

Overall ranking

Here’s the table with the overall results. The file managers were compared in terms of 1. memory consumption (most important for me and thus weighted *3), 2. disk space used (weighted *2) and 3. size of packages to download:

Rank File manager Version
01 Dfilebrowser 1.1
02 ScOpe GIT20130121
03 QtFM 5.1
04 Dino 0.5
05 NewBreeze 1.1.1
06 Andromeda 0.2.1
07 Hamsi Manager 1.1
08 Dolphin 4.9.5

RAM usage

Here’s the table comparing memory use:

<250 MB 251 – 275 MB 276 – 300 MB > 300 MB
Rank File manager Version
01 Dfilebrowser 1.1 230 MB
02 ScOpe GIT20130121 233 MB
03 QtFM 5.1 236 MB
04 Dino 0.5 240 MB
05 NewBreeze 1.1.1 252 MB
06 Andromeda 0.2.1 260 MB
07 Hamsi Manager 1.1 305 MB
08 Dolphin 4.9.5 306 MB

Drive space needed

Here’s the drive space table:

<50 MB 50 – 100 MB 101 – 300 MB > 300 MB
Rank File Manager Version Disk space used
01 Dfilebrowser 1.1 +2 MB
02 Dino 0.5 +3 MB
02 QtFM 5.1 +3 MB
02 ScOpe GIT20130121 +3 MB
03 Andromeda 0.2.1 +64 MB
04 NewBreeze 1.1.1 +74 MB
05 Hamsi Manager 1.1 +295 MB
06 Dolphin 4.9.5 +598 MB

Download size

And the download size table:

<5 MB 6 – 25 MB 26 – 50 MB >50 MB
Rank File Manager Version size
01 Dfilebrowser 1.1 +70 KB
02 QtFM 5.1 +200 KB
03 ScOpe GIT20130121 +243 KB
04 Dino 0.5 +256 KB
05 NewBreeze 1.1.1 +528 KB
06 Andromeda 0.2.1 +13 MB
07 Hamsi Manager 1.1 +51 MB
08 Dolphin 4.9.5 +109 MB

Conclusion

Not too many surprises here. There are some light-weight file managers and a few which offer more features but are also much more heavy weight. Especially in terms of drive space needed and download size the light-weight ones are rather close to each other. Because of that the RAM comparison came out to be identical to the overall rating. Dfilebrowser is the clear winner in our comparison – it scored the first rank in all three categories. ScOpe and QtFM are doing very well, too. Hamsi Manager is a rather ressource heavy file manager and it’s not surprising either that KDE’s Dolphin is the most heavy of the tested applications.

What’s next?

The next entry will take a look at the Qt-based text editors (of which there’s also quite some around).

Qt-based applications #2: File managers (1/2)

In this post we’ll take a look at some Qt-based file managers. Since there’s quite a lot of them, let’s start right away!

All screenshots from this entry on are in 1024×768 resolution. So if you click on any of the pictures you’ll get a bigger one where you might actually see something…

The candidates

Here are the file managers that were tested (in alphabetical order):

Not tested

Some of the file managers didn’t work right away. These are the ones that I could not get to work at all and that were not tested:

  • Double Commander (“Total Commander” inspired. Would have been especially interesting since it’s written in Pascal. However it won’t compile on my current Arch VM.)
  • Qefem (Won’t compile.)
  • QtCommander (Also “TC” inspired. Doesn’t work with Qt4.)
  • QtFileMan (Won’t compile.)
  • Synopson (Available as binary only, no source. Unacceptable.)

If anybody can get one or more of these to work on Arch, please let me know (send me PKGBUILDs?). And also tell me if you think that I forgot anything interesting!

Testing system

For this test I’m using the same VM as in my previous Qt application test. I haven’t updated it since then.

Andromeda

Andromeda is a cross-platform file manager based on Qt.

Razor-qt with Andromeda

Installation

pacman -U andromeda-0.2.1-1-x86_64.pkg.tar.xz (1094280 Bytes / 1,1 MB)
(other packages downloaded as dependencies: 11448320 Bytes / 11,4 MB)

Statistics

Memory usage after starting up Razor-qt and opening Andromeda via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ Andromeda 0.2.1
MemTotal: 4053592 kb
MemFree: 3787652 kb
Buffers: 10716 kb
Cached: 97100 kb
Rootfs: 960924 / 939M
RAM used at startup: 265940 / ~260 MB
Disk space (less razor system): 66000 / ~64 MB

Dfilebrowser

Dfilebrowser is a Qt file manager meant for mobile devices – but of course it works on the pc, too.

Razor-qt with Dfilebrowser

Installation

pacman -U dfbrowser-17-1-x86_64.pkg.tar.xz (68688 Bytes / 68,7 kB)

Statistics

Memory usage after starting up Razor-qt and opening Dfilebrowser via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ Dfilebrowser 1.1
MemTotal: 4053592 kb
MemFree: 3817596 kb
Buffers: 10148 kb
Cached: 76348 kb
Rootfs: 897172 / 877M
RAM used at startup: 235996 / ~230 MB
Disk space (less razor system): 2248 / ~2 MB

Dino

Dino is simple Qt file manager that does however come with some nice features (like a built-in text editor and such).

Razor-qt with Dino

Installation

pacman -U dino-dfm-0.5-1-x86_64.pkg.tar.xz (256116 Bytes / 256,1 kB)

Statistics

Memory usage after starting up Razor-qt and opening Dino via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ Dino 0.5
MemTotal: 4053592 kb
MemFree: 3807736 kb
Buffers: 10468 kb
Cached: 79112 kb
Rootfs: 898044 / 877M
RAM used at startup: 245856 / ~240 MB
Disk space (less razor system): 3120 / ~3 MB

Dolphin

Dolphin is the standard file manager of KDE. As such it has a lot of dependencies and is very heavy!

Razor-qt with Dolphin

Installation

pacman -S kdebase-dolphin (108677120 Bytes / 108,7 MB)

Statistics

Memory usage after starting up Razor-qt and opening Dolphin via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ Dolphin 4.9.5
MemTotal: 4053592 kb
MemFree: 3739960 kb
Buffers: 17320 kb
Cached: 124660 kb
Rootfs: 1507336 / 1.5G
RAM used at startup: 313632 / ~306 MB
Disk space (less razor system): 612412 / ~598 MB

Hamsi Manager

The Hamsi Manager is an advanced Qt file manager with a lot of extras.

Razor-qt with Hamsi Manager

Installation

pacman -U hamsimanager-1.1-1-any.pkg.tar.xz (1173980 Bytes / 1,2 MB)
(other packages downloaded as dependencies: 49428480 Bytes / 49,4 MB)

Statistics

Memory usage after starting up Razor-qt and opening Hamsi Manager via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ Hamsi Manager 1.1
MemTotal: 4053592 kb
MemFree: 3741396 kb
Buffers: 14596 kb
Cached: 107632 kb
Rootfs: 1197212 / 1.2G
RAM used at startup: 312196 / ~305 MB
Disk space (less razor system): 302288 / ~295 MB

NewBreeze

NewBreeze is a reasonably light-weight Qt file manager.

Razor-qt with NewBreeze

Installation

pacman -U newbreeze-1.1.1-2-x86_64.pkg.tar.xz (528288 Bytes / 528,3 kB)

Statistics

Memory usage after starting up Razor-qt and opening NewBreeze via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ NewBreeze 1.1.1
MemTotal: 4053592 kb
MemFree: 3795320 kb
Buffers: 10776 kb
Cached: 93268 kb
Rootfs: 969916 / 948M
RAM used at startup: 258272 / ~252 MB
Disk space (less razor system): 74992 / ~74 MB

QtFM

QtFM is meant as a light-weight Qt file manager but it is already a bit on the heavy side. However it’s rather feature rich.

Razor-qt with QtFM

Installation

pacman -S qtfm (200108 Bytes / 200,1 kb)

Statistics

Memory usage after starting up Razor-qt and opening QtFM via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ QtFM 5.5
MemTotal: 4053592 kb
MemFree: 3811512 kb
Buffers: 10312 kb
Cached: 79556 kb
Rootfs: 897684 / 877M
RAM used at startup: 242080 / ~236 MB
Disk space (less razor system): 2976 / ~3 MB

ScOpe

ScOpe is the file manager that belongs to the “Sapphire Desktop” project. It’s developed with focus on usability.

Razor-qt with ScOpe

Installation

libdelta-git-20130121-1-x86_64.pkg.tar.xz (139548 Bytes / 139,5 kB)
scope-git-20130121-1-x86_64.pkg.tar.xz (103936 Bytes / 103,9 kB)

Statistics

Memory usage after starting up Razor-qt and opening ScOpe via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ ScOpe GIT20130121
MemTotal: 4053592 kb
MemFree: 3815308 kb
Buffers: 10300 kb
Cached: 78244 kb
Rootfs: 898332 / 878M
RAM used at startup: 238284 / ~233 MB
Disk space (less razor system): 3408 / ~3 MB

Whatโ€™s next?

Since all these values can be a bit confusing, I’ll dedicate another post to the file managers. The next one will feature a table so that comparison is easy. That’s why this post goes without a conclusion for a change.

Qt-based applications #1: Terminal emulators

Alright, finally time for a new entry! I got a nice new laptop – my first one that came Linux pre-installed. It’s currently running Mint (which is ok, I guess, since my wife uses it, too). I didn’t find the time to crawl through all the GB of my old data, so I don’t have everything back to normal, yet. But let’s start with the promised qt-applications test anyways!

The candidates

Taking a quick look around, I found two terminal emulators which are built upon Qt:

(I’m not a KDE/Qt user. So if I missed anything interesting, feel free to tell me!)

Testing system

For the coming tests I set up a new, clean Arch VM today (20.01.2013). This basic machine looks like this:

Arch Linux “base”
MemTotal: 4053592 kb
MemFree: 3972512 kb
Buffers: 5688 kb
Cached: 19920 kb
Rootfs: 612312 / 598M
RAM used at startup: 81080 / ~79 MB

Then I installed Razor-qt (built on a different VM):

pacman -S xorg-server, xorg-xinit, xf86-video-vesa, openbox (packages size: 56647680 Bytes / 56,6 MB)
pacman -U razor-qt-0.5.1-1-x86_64.pkg.tar.xz (6922372 Bytes / 6,9 MB)

Memory usage right after starting up Razor-qt (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux + Razor-qt (0.5.1)
MemTotal: 4053592 kb
MemFree: 3815280 kb
Buffers: 10316 kb
Cached: 82836 kb
Rootfs: 894924 / 874M
RAM used at startup: 238312 / ~233 MB
Disk space (less basic system): 282612 / ~276 MB

Konsole

Konsole is the standard KDE terminal emulator. It’s quite huge since it pulls in half of KDE…

Razor-qt with Konsole

Installation

pacman -S kdebase-konsole (packages size: 108032000 Bytes / 108 MB)

Statistics

Memory usage after starting up Razor-qt and opening Konsole via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ Konsole 4.9.5
MemTotal: 4053592 kb
MemFree: 3770416 kb
Buffers: 16768 kb
Cached: 107964 kb
Rootfs: 1503564 / 1.5G
RAM used at startup: 283176 / ~277 MB
Disk space (less razor system): 608640 / ~594 MB

QTerminal

QTerminal is a more light-weight, tabbed terminal emulator based on Qtermwidget. There’s something wrong with the font height on my system, so the console text looks weird.

Razor-qt with QTerminal

Installation

pacman -U qtermwidget-git-20130120-1-x86_64.pkg.tar.xz (188800 Bytes / 188,8 kB)
pacman -U qterminal-git-20130120-1-x86_64.pkg.tar.xz (89980 Bytes / 90,0 kB)

Statistics

Memory usage after starting up Razor-qt and opening QTerminal via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ QTerminal git-20130120
MemTotal: 4053592 kb
MemFree: 3811560 kb
Buffers: 10512 kb
Cached: 78216 kb
Rootfs: 897752 / 877M
RAM used at startup: 242032 / ~236 MB
Disk space (less razor system): 2828 / ~3 MB

Conclusion

Here we have two Qt terminal emulators. One is rather big and requires almost 600 (!) MB of disk space with its dependencies and uses 44 MB of RAM on the 4GB testing system. The other one is far more frugal with just 3 MB of disk space required and another 3 MB of RAM used… Yes, Qt applications can still be nice and small! ๐Ÿ™‚

What’s next?

Next we’ll take a look at file managers based on Qt. There are LOTS of them, so the next post will be far longer than this one!

Essential graphical applications

After some entries about the “Desktop Demo DVD” we’re now coming back to planing the experimental new distribution that EERIE is actually about.

The most visible decision every distribution has to make is certainly which applications it features on a standard installation. This post is to examine which kinds of programs are to be considered essential or at least important.

Distributions and applications

Each GNU/Linux distro comes with a bunch of standard applications. In some cases there are few such programs and in others there are a lot of them. Usually there’s some kind of pattern which the selection follows. For example one might preselect the candidates according to how slim or how feature-rich they are or by the toolkit they use.

Using Linux we’re really spoiled when it comes to loads of software easily accessible and often already pre-installed. Of course: Windows comes with a calculator, too; there’s notepad, paint, the internet explorer and a few other applications. But think of a fresh install (and consider for a second how much space that system occupies on your drive!): How to play your music encoded in Ogg Vorbis? How to look at a pdf document? How to even burn an iso to a CD/DVD/BluRay?

If you’re using a distribution like e.g. Linux Mint you won’t have any such problems. Right after installation it can cope with all these tasks. It can also download large files via torrent, it let’s you access Jabber, ICQ, Yahoo!, etc, and much more. And even if you’re using a distro with a more light-weight approach, they’re usually still just a single console command away.

We are not to examine particular programs here and compare them with each other (Something like that will be done in a future blog post). This entry is simply meant to collect which kinds of programs any distribution should provide so that it doesn’t feel lacking anything essential. Of course there are many things that can be done just as well using the console. But in EERIE’s case planning is for a light-weight desktop distribution, isn’t it?

Essential applications

  1. The most important application, I’d say, is a terminal emulator. Without it I feel close to being locked out of my system. And as soon as you have one, you can use your pc in graphical mode even if it lacks any other graphical applications!
  2. Second is a file manager. Without it a classical DE is not worth much! It can be far more comfortable to browse the files on your system graphically.
  3. Third comes a text editor, at least for me. Not being able to even manipulate a simple configuration file or something like that just feels horrible.

There are some more programs that I’d call “essential” but can’t decide which “rank” they take. So the following list is an unsorted one:

  • A web browser so that you have access to the net.
  • A simple picture viewer that supports at least the most common graphic formats.
  • A pdf viewer to render pdf documents.
  • A music player so you can listen to your music collection.
  • A word processor to compose documents.
  • A CD/DVD recording software.

This is – from my point of view – more or less the core of applications that absolutely must be available and that can easily make a distro unusable if they are missing.

Important programs

Other than these “core applications” there are of course some more which are likely to be painfully missed if not available. I’ll try to compile another unordered list for them:

  • A movie player that lets you watch some videos.
  • A spread sheet application.
  • An organizer that lets you keep track of your appointments.
  • An instant messenger so you can keep in touch with your contacts
  • An archiver to extract archives or compress files.
  • An image manipulation programm.

Other programs

The above mentioned software does of course not yet cover all needs. There’s no scanning application yet, no torrent client, no hex editor or things like that.

However we have to draw the line somewhere. But since I’m going to explore the world of graphical applications some more with my next posts, I wanted to write about what I consider essential or important, first. Please feel free to comment on the topic and tell me if you think that I’m missing something that’s important or even essential for you or if you could well live without something that I thought was a must-have.

What’s next?

I’ll compile a list of Qt-based applications next and take a little look at them.

DDD #3: Advanced Live-CD/DVD creation

In post 19 (Creating an Arch Live-CD) I blogged about building a simple Live-CD on Arch Linux. It was the summary of my first attempts relating to that topic. In the meantime I created another ISO and published it as a first preview of my “Desktop Demo DVD” project in post 21 (The Desktop Demo DVD).

This new entry will describe how my “DDD” was built (and thus how you add things like a graphical login manager and add users to a live medium).

Preparations

First I create a new virtual machine to keep things clean and tidy and then build and install the archiso tool. Next is building AUR packages edelib and ede as well as creating a custom repo for them. (I won’t repeat it in detail here. You can look up both things in post #19 if you wish).

Configuring archiso

Just like in my previous building attempt, it’s necessary to create a new directory and copy over the “releng” dir from archiso. After that the various steps at configuring the iso can be taken.

Packages

The first thing to do is adding the right packages to the file packages.i686. Since we want a graphical environment, it’s a good idea to have xorg-server installed (we’re going to use a graphical login manager this time, so we can do without xorg-xinit).

Since the system is meant to run on about every hardware, X11 needs the proper graphic drivers. You may want to look for all xf86-video-* packages and add them. The only issue with that was that the openchrome and unichrome drivers were conflicting, but later (and older) one has been removed from the “extra” repository recently. Whatever you do, be sure to leave xf86-video-vesa in there – that’s the fallback driver that will work on most machines even if none of the others does (which is pretty rare however). Also it might be a good idea to add xf86-input-evdev just to make sure, you can use e.g. your keyboard in X. Adding virtualbox-guest-modules, too, will let X.org use the appropriate driver if running inside a VirtualBox VM.

Next I added the desktop environments that I wanted to be available. I chose mate (remember to add the additional repos for it and ede!), xfce4, lxde and e-svn as well as libxpm (needed by ede) and the packages edelib and ede. Finally the display manager lxdm is added as well.

Display manager

Thanks to systemd, much of the wiki page about archiso is outdated and no longer of any use. This is the case e.g. when it comes to starting the display manager automatically after booting. It suggests using an inittab and we could actually do so and use a sysVinit compatibility package as well. However it was already announced that this would be dropped in the forseeable future so it’s best to do things the proper way right from the beginning.

LXDM comes with its own service file for usage with systemd. So the default command to configure the system for starting it after booting is systemctl enable lxdm.service. However this will of course not work in our case: First we don’t even have LXDM installed on building system and second – even if we had – enabling it there would not affect the live system. However for that reason there’s a folder called root image where we can make changes that will affect it!

So what does the above command really do? No more actually than creating a softlink! Of course we can do that by hand, too. Let’s change our PWD (present working directory) to /root/archlive/releng/root-image/etc/systemd/system. Now let’s create the proper link, shall we? The command for that is ln -s /usr/lib/systemd/system/lxdm.service display-manager.service.

Next step is creating a new directory (that is normally created when LXDM is installed): mkdir ../../lxdm and then I change into that dir. Afterwards I install lxdm on my build system and copy its configuration file into the new dir: cp /etc/lxdm/lxdm.conf . (if you’ve got LXDM installed on any other system, you can of course also copy it from there). Now it’s time to edit lxdm.conf: I simply add user “arch” to the blacklist (right at the end of the default configuration file). It’s a user automatically created by the install scripts and I have not yet looked into how to prevent its creation. For that reason I decided to just block it there so that it’s not offered by LXDM.

Adding a user

This step is important since we disabled the user “arch” and cannot log in as “root”. The solution suggested for this on the Arch wiki is simply copying over the files passwd, shadow and group (all located in /etc) from a system set up the way we want it. This is actually a fine way and since we’re using virtual machines anyway, it does not hurt to simply clone one, adding the desired user (“desktopdemodvd” in my case) there and copying said files over to root-img/etc on our building VM (using a USB device is probably the most confortable way).

That was the easy part. Many DEs will however not work if there’s no proper /home/$username directory present. We could of course create one in root-image/home, but that would be owned by root on our live system so that’s not quite what we want. Again the wiki is outdated (while I’m at it anyway, I should dedicate some love to it when I’m done here, I guess). We want to do things the systemd way! So how to do it in this case? Let’s write a new service for it (woah)!

Luckily things are easier than it might look first. Ok, I admit that it took me a few attempts before things finally worked right. But you can save yourself some time and simply copy what I did. Change into the dir root-img/etc/systemd/system again. Now create a new service file – I called mine “autostart.service”. The content of my file is like this:

[Unit]
Description=Autostart

[Service]
Type=oneshot
ExecStart=/bin/mkdir /home/desktopdemodvd
ExecStart=/bin/chown desktopdemodvd /home/desktopdemodvd

[Install]
WantedBy=multi-user.target

Note: “ExecStart=/bin/chown desktopdemodvd /home/desktopdemodvd” is one line!

Done configuring

Yes, if I remember correctly, that was all. You should be able to build the iso now.

I don’t know if I did any changes beside these, but this blog entry at least shows two important things: Adding users and using a graphical login manager.

There are of course a lot of things you could customize as well and perhaps I’m going to explore some of these in the future, too. But right now I’m going to wait and see what happens with the “DDD”.

What’s next?

My next post will deal with what should be considered essential graphical applications – and afterwards we’re getting back into the world of toolkits.

DDD #2: The “Desktop Demo DVD”!

In the last entry I discussed the situation of Linux desktop environments in general and how it encourages taking various less-known DEs into account for your system, too. Now it’s time to talk about the first alpha version of the actual DDD!

If you just want to download it, have a look here.

The idea behind the DDD

There are four reasons why I decided to create the “DDD”:

  1. Because I found out that there are many Linux users today who would like to know more about alternative DEs
  2. Because I think the less known DEs deserve some publicity
  3. Not every DE can be installed easily on each distro and thus it can take a lot of time and effort to try them out
  4. Because I’m interested in different DEs and building “DDD” is another informative thing

The version I release today is just a little preview. But before I describe what 0.1 includes right now, I’d like to share my vision of what DDD 1.0 should be.

Vision

  • A perfect Desktop Demo DVD should come with all available desktop environments the Linux world has to offer.
  • If possible it should also showcase some default applications of the particular DE which are not in the menus of the other ones so things don’t get confusing.
    (I think that this can be done with the desktop files or probably by other means.)
  • Localization at least for the most common languages.
    (Better: As much languages supported as possible.)
  • Only list the real DEs in the display manager (and not probably confusing variants with different WMs).
  • A short html tutorial which helps the users to discover the most important features of the various DEs could be very beneficial.
  • Some nice artwork would be great, too.
  • A few other “cosmetics”.

Desktop Demo DVD

This project is to provide an ISO file that can be downloaded and used in either a virtual machine or burned to a disk and then used with real hardware. It is meant to showcase the various DEs that work with Linux and thus give anybody interested the oportunity to quickly take a look at them without all the hassle (i.e. finding out that they even exist, often building them yourself, getting them to run on your distro, etc.).

You can download version 0.1 of it from Bitshare.

If you want to check the integrity of the downloaded file, you can just put this into a new file and use md5sum:

f9d57debb8d83cba46f4dada042133a5 desktop_demo_dvd_0.1.iso

As you would guess when you read the version number, this release is mearly a first attempt. Right now it fits on a CD but that’s going to change. I’ll try to improve DDD if I find time for it and then release a second version.

Currently it provides a graphical login (using lxdm) and comes with as much as 5 DEs:

  • MATE
  • Xfce
  • LXDE
  • Enlightenment 17
  • Equinox DE

Using the DDD

If all goes well you should be greeted by the graphical login manager LXDM after startup. First open the list of available desktop environments (if you don’t change anything, LXDE will be started as default). To do so, click on the list to open it.

Graphical login: First step

Now select which one to start and then click on the user “desktopdemodvd”.

Graphical login: Second step

The password for the primary user desktopdemodvd is simply ddd. Enter it and then press the return key.

Graphical login: Last step

That’s it! The DE you selected from the list should be starting.

Issues with version 0.1

There are a few issues I didn’t find a solution for yet, but I didn’t want to postpone things again for an even longer delay. Probably the worst thing is performance: Even when using the ISO in a virtual machine on a fast PC it takes quite a while until the DEs finish loading. Please be patient. Because of that I can’t recommend burning it and using a disk. Also for some reason loging out of E-17 does not work.

Please report other problems, make suggestions and give feedback of any kind. I’d very much appreciate it!

What’s next?

I can’t promise when (or if!) a new DDD version will be released. The next post will be about the technical side of it and describe how to build an extended Arch live-cd including users other than root and with a graphical login (display manager).