Top things that I missed in 2015

Another year of blogging comes to an end. It has been quite full of *BSD stuff so that I’d even say: Regarding this blog it has been a BSD year. This was not actually planned but isn’t a real surprise, either. I’ve not given up on Linux (which I use on a daily basis as my primary desktop OS) but it’s clear that I’m fascinated with the BSDs and will try to get into them further in 2016.

Despite being a busy year, there were quite a few things that I would have liked to do and blog about that never happened. I hope to be able to do some of these things next year.

Desktops, toolkits, live DVD

One of the most “successful” (in case of hits) article series was the desktop comparison that I did in 2012. Now in that field a lot has happened since then and I really wanted to do this again. Some desktops are no longer alive others have become available since then and it is a sure thing that the amount of memory needed has changed as well… πŸ˜‰

Also I’ve never been able to finish the toolkit comparison which I stopped in the middle of writing about GTK-based applications. This has been started in 2013 so it would also be about time. However my focus has shifted away from the original intend of finding tools for a light-weight Linux desktop. I’ve become involved with the EDE project (“Equinox Desktop Environment”) that uses the FLTK toolkit and so people could argue that I’m not really unbiased anymore. Then again… I chose to become involved because that was the winner of my last test series – and chances are that the reasons for it are still valid.

And then there’s the “Desktop Demo DVD” subproject that never really took off. I had an Arch-based image with quite some desktops to choose from but there were a few problems: Trinity could not be installed alongside KDE, Unity for Arch was not exactly in good shape, etc. But the biggest issue was the fact that I did not have webspace available to store a big iso file.

My traffic statistics show that there has been a constant interest in the article about creating an Arch Linux live-CD. Unfortunately it is completely obsolete since the tool that creates it has changed substantially. I’d really like to write an updated version somewhen.

In fact I wanted to start over with the desktop tests this summer and had started with this. However Virtual Box hardware acceleration for graphics was broken on Arch, and since this is a real blocker I could not continue (has this been resolved since?).

OSes

I wrote an article about HURD in 2013, too, and wanted to re-visit a HURD-based system to see what happened in the mean time. ArchHURD has been in coma for quite some time. Just recently there was a vital sign however. I wish the new developer best luck and will surely do another blog post about it once there’s something usable to show off!

The experiments with Arch and an alternative libc (musl) were stopped due to a lack of time and could be taken further. This has been an interesting project that I’d like to continue some time in some form. I also had some reviews of interesting but lesser known Linux distros in mind. Not sure if I find time for that, though.

There has been a whole lot going about both FreeBSD and OpenBSD. Still I would have liked to do more in that field (exploring jails, ZFS, etc.). But that’s things I’ll do in 2016 for sure.

Hardware

I’ve played a bit with a Raspberry 2 and built a little router with it using a security orientated Linux distro. It was a fun project to do and maybe it is of any use to somebody.

One highlight that I’m looking forward to mess with is the RISC-V platform, a very promising effort to finally give us a CPU that is actually open hardware!

Other things

There are a few other things that I want to write about and hope to find time for soon. I messed with some version control tools a while back and this would make a nice series of articles, I think. Also I have something about devops in mind and want to do a brief comparison of some configuration management tools (Puppet, Chef, Salt Stack, Ansible – and perhaps some more). If there is interest in that I might pick it up and document some examples on FreeBSD or OpenBSD (there’s more than enough material for Linux around but *BSD is often a rather weak spot). We’ll see.

Well, and I still have one article about GPL vs. BSD license(s) in store that will surely happen next year. That and a few topics about programming that I’ve been thinking about writing for a while now.

So – goodbye 2015 and welcome 2016!

Happy new year everyone! As you can see, I have not run out of ideas. πŸ™‚

Advertisements

An interview with the Nanolinux developer

2014 is nearly over and for the last post this year I have something special for you again. Last year I posted an interview with the EDE developer and I thought that another interview would conclude this year of blogging quite fine.

In the previous post I reviewed Nanolinux (and two years ago XFDOS). Since I was in mail contact with the author about another project as well, it suggested itself that I’d ask him if he’d agree to give me an interview. He did!

So here’s an interview with Georg Potthast (known for a variety of projects: DOSUSB, Nanolinux and Netrider – to just name some of them) about his projects, the FLTK toolkit, DOS and developing Open Source software in general. Enjoy!

Interview with Georg Potthast

This interview was conducted via email.

Please introduce yourself first: How old are you and where are you from?

I am 61 years old and live in Ahlen, Germany. This is about 30 minutes drive from Dortmund where they used to brew beer and where the BVB Dortmund soccer team is currently struggling.

Do you have any hobbies which have nothing to do with the IT sector?

Not really. I did some Genealogy, which has to do a lot with IT these days. But now I have several IT projects I am working on.

DOS

You’re involved in the FreeDOS community and have put a lot of effort into XFDOS. A lot of people shake their heads and mumble something like “It’s 2014 now and not 1994…” – you know the score. What is your motivation to keep DOS alive?

I have been using DOS for a long time and wish it would not go away completely. So I developed these DOS applications, hoping to get more people to use DOS. But I have to agree that I have not been successful with that.

Potential software developers find only very few users for their applications which is demotivating. Also there is simply no hardware available today that is limited so much that you better use DOS on it. Everything is 32/64 bit, has at least 4 GB of memory and terabytes of disk space. And even the desktop PC market is suffering from people moving to tablets and smartphones.

People are still buying my DOSUSB driver frequently. They are using it mostly for embedded applications which shall not be ported to a different operating system for one reason or another.

Do you have any current plans regarding DOS?

I usually port my FLTK applications to DOS if it is not too much effort to do so. So they are available for Linux, Windows and DOS. Such as my FlDev IDE (Link here).

Recently I made a Qemu/FreeDOS bundle named DOS4WIN64 (Link here) that you can run as an application on any Windows 7/8 machine. This includes XFDOS. I see this as a path to run 16bit applications on 64bit Windows.

How complicated and time consuming is porting FLTK applications from Linux to DOS or vice versa?

It depends on the size and the dependencies on external libraries. I usually run ./configure on Linux and then copy the makefile to DOS where I replace-lXlib with -lNXlib plus -lnano-X. Then, provided the required external libraries could be downloaded from the djgpp site, it will compile if the makefile is not too complicated (recursive). Sometimes I also compile needed libraries for DOS which is usually not difficult if they have a command line interface.

You then have to test if all the features of the application work on DOS and make some adjustments here and there. Often you can use the Windows branch if available for the path definitions.

Porting DOS applications to Linux can be more complicated than vice versa.

Linux

For how long have you been using Linux?

I have been using Linux on and off. I began using SCO-Unix. However, I did not like setting things up with configuration files (case sensitive) scattered over many directories. It took me over a week to get serial communications to work to connect a modem. When I asked Linux developers for help they recommended to recompile the kernel first – which means they did not know how to do that either. So I returned to DOS at that time. But I have been using Linux a lot for several years now.

What is your distribution of choice and why?

I mainly use SUSE but I think Ubuntu may work just as well. This may sound dull but you do not have to spend time on adding drivers to the operating system or porting the libraries you need. The mainstream Linux distributions are well tested and documented and you do not have to spend the time to tailor the distro to your needs. They do just much more than you need so you are all set to start right away.

My own distro, Nanolinux, is a specialized distro which is meant to show how small a working Linux distro can be. It can be used on a flash disk, as an embedded system, a download on demand system or to quickly switch to Linux from within Windows.

However, if you have a 2 Terabyte hard disk available I would not use Nanolinux as the main distribution.

FLTK

Which programming languages do you prefer?

I like Assembler. To be able to use X11 and FLTK I learned C and C++ which I currently use. I have not done any assembler in a while though.

You seem to like the idea of minimalism. Do you do use those minimalist applications on a daily base or are they more of a nice hobby?

Having a DOS and assembler background I always try not use more disk space than necessary. Programming is just my hobby.

Many of your projects use the FLTK toolkit. Why did you choose this one and not e.g. FOX?

I had ported Nano-X to DOS to provide an Xlib alternative for DOS developers. In addition I ported FLTK to DOS as well since FLTK can be used on the basis of Nano-X. So I am now used to FLTK.

Compared to the more common toolkits, FLTK suffers from a lack of applications. Which three FLTK applications that don’t exist (yet) do you miss the most?

I think FLTK is a GUI toolkit for developers, so it is not so important what applications are available based on FLTK.

If you look at my Nanolinux – given I add the NetRider browser and my FlMail program to the distro – it comes with all the main office applications done in FLTK. However, the quality of these applications is not as good as Libre Office, Firefox or Gimp. I do not expect anyone to write Libre Office with a FLTK GUI.

When you awake at night, a strange light surrounds you. The good FOSS fairy floats in the air before you! She can do absolutely everything FOSS related; whether it’s FLTK 3 being completed and released this year, a packaging standard that all Linux distros agree on or something a bit less unlikely. πŸ˜‰ She grants you three wishes!

As with FLTK 3 I wish it would change its name and the development would concentrate on FLTK 1.3.

Regarding the floating fairy I would wish the internet would be used by nice and friendly people only. Currently I see it endangered by massive spam, viruses, criminals and even cyber war as North Korea apparently did regarding the movie the ruling dictator wanted to stop being shown.

Back to serious. What do you think: Why is FLTK such a little known toolkit? And what could be done about that?

I do not think it is little known, just most people use GTK and so this is the “market leader”. If you work in a professional team this will usually decide to go for GTK since most members will be familiar with that.

What could be done about that? If KDE and Gnome would be based on FLTK I think the situation will change.

From your perspective of a developer: What do you miss about FLTK that the toolkit really should provide?

Frankly speaking, as a DOS developer the alternative would be to write your own GUI. And FLTK provides more features than you could ever develop on your own.

What I do not like is the lack of support for third party schemes. Dimitrj, a Russian FLTK developer who frequently posts as “kdiman” on the FLTK forums, created a very nice Oxy scheme. But it is not added to FLTK since the developers do not have the time to test all the changes he made to make FLTK look that good.

What do you think about the unfortunate FLTK 2 and the direction of FLTK 3?

I think these branches have been very unfortunate for FLTK. Many developers expected FLTK 2 to supersede FLTK 1.1 and waited for FLTK 2 to finish before developing an FLTK application. But FLTK 2 never got into a state where it could replace FLTK 1.1. Now the same seems to happen with FLTK 3.

So they should have named FLTK2/3 the XYZ-Toolkit and not FLTK 2 to avoid stopping people to choose FLTK 1.1.

Currently there is no development on FLTK 2/3 that I am aware of and I think the developers should concentrate on one version only. FLTK 1.3 works very well and does all that you need as a software developer as far as I can say.

Somebody with a bit of programming experience and some free time would like to get into FLTK. Any tips for him/her?

I wrote a tutorial which should allow even beginners in C++ programming to use FLTK successfully (Link here).

Nanolinux

You’ve written quite a number of such applications yourself. Which of your projects is the most popular one (in terms of downloads or feedback)?

This is the Nanolinux distro. It has been downloaded 30.000 times this year.

NanoLinux… Can you describe what it is?

Let me cite Distrowatch, I cannot describe it better: Nanolinux is an open-source, free and very lightweight Linux distribution that requires only 14 MB of disk space. It includes tiny versions of the most common desktop applications and several games. It is based on the “MicroCore” edition of
the Tiny Core Linux distribution. Nanolinux uses BusyBox, Nano-X instead of X.Org, FLTK 1.3.x as the default GUI toolkit, and the super-lightweight SLWM window manager. The included applications are mainly based on FLTK.

After compiling the XFDOS distro I thought I would gain more users if I would port it to Linux. The size makes Nanolinux quite different from the others and I got a lot of downloads and reviews for it.

The project is based on TinyCore which makes use of FLTK itself. Is that the reason you chose this distro?

TinyCore was done by the former main developer of Damn Small Linux. So he had a lot of experience and did set up a very stable distro. Since I wanted to make a very small distro this was a good choice to use as a base. And I did not have to start from scratch and test that part of the distro forever.

NanoLinux uses an alternative windowing system. What can you tell us about the differences between NanoX and Xorg’s X11?

Nano-X is simply a tiny Xlib compatible library which has been used in a number of embedded Linux projects. Development started about 15 years ago as far as I recall. At that time many Linux application developers used X11 directly and therefore were willing to use an alternative like nano-X for their projects.

Since nano-X is not fully compatible to X11, a wrapper called NXlib was developed, which provides this compatibility and allows to base FLTK and other X11 applications on nano-X without code change. The compatibility is not 100% of cause, it is sufficient for FLTK and many X11 applications.

Since nano-X supported DOS in the early days I took this library and ported the current version to DOS again.

Netrider

The project you are working on currently is NetRider, a browser based on webkit and FLTK. Please tell us how you came up with the idea for it.

Over the years I looked at other browser applications and thought how I could build my own browser, just out of interest. Finally Laura, another developer from the US, and I discussed it together. She came up with additional ideas and thoughts. That made me have a go at WebKit with FLTK.

What are your aims for NetRider?

I wanted to add a better browser to my Nanolinux distro replacing the Dillo browser. Also, as a FLTK user I wanted to provide a FLTK GUI for the WebKit package as an alternative to GTK and Qt.

There’s also the project Fifth which has quite similar aims at first sight. Why don’t you work together?

Lauri, the author of Fifth, and I started out about the same time with our FLTK browser projects, not knowing of each other’s plans. Now our projects run in parallel. Even though we both use FLTK, the projects are quite different.

We have not discussed working together yet and our objectives are different. He wants to write an Opera compatible browser and competes with the Otter browser while I am satisfied to come up with something better than Dillo.

I did not ask Lauri whether he thinks we should combine the projects. I am also not sure if this would help us both because we implemented different WebKit APIs for our browsers so we would have to make a WebKit library featuring two APIs. This could be done though. Also he is not interested in
supporting Windows which Laura and I want to support.

Would you say that NetRider is your biggest project so far? And what plans do you have for it?

Setting up Nanolinux and developing/porting all the applications for it was a big project too, and I plan to make a new release beginning of next year.

As with NetRider it depends if people like to use it or are interested to develop for / port it. Depending on the feedback I will make my plans. Recently I added some of the observations I got from beta testers, did support for additional languages, initial printing support etc.

The last one is yours: Which question would you have liked me to ask in addition to those and what is the answer to it?

I think you already asked more questions than I would have been able to come
up with. Thank you for the interesting questions.

Thanks a lot Georg, for answering these questions! Best wishes for your current and future projects!

What’s next?

I have a few things in mind… But I don’t know yet which one I’ll write about next. A happy new year to all my readers!

Tiny to the extreme: Nanolinux

It has been more than two years since I wrote about XFDOS, a graphical FreeDOS distribution with the FLTK toolkit and some applications for it (the project’s home is here.)

Mr. Potthast didn’t stop after this achievement however. Soon afterwards he published Nanolinux. And now I finally found the time to re-visit the world of tiny FLTK applications – this time on a genuine Linux system! And while it shows that it is closely related to XFDOS (starting with the wallpaper), Nanolinux does not follow the usual way at all according to which newer things are “bigger, badder and better”. It is rather “even smaller, more sophisticated and simple to use”!

I needed three attempts to catch the startup process properly because Nanolinux starts up very fast. Probably the most important difference from the DOS version is that Nanolinux can run multiple applications at the same time (which is something that goes without saying today). But there’s of course some more to it. If it weren’t then this review wouldn’t make much sense, would it?

The startup process of Nanolinux

TinyCore + NanoX + FLTK apps = Nanolinux?

Yes, that is what Nanolinux basically is. But that’s in fact more than you might expect. The first thing that is noteworthy is the size of Nanolinux: Just like the name suggests, it’s very small. It runs on systems with as little as 64 MB of RAM – and the whole iso for it is only 14 MB in size.

The Nanolinux desktop (second cursor is from the host machine)

While many people will be impressed by this fact I can hear some of you yawn. Don’t dismiss the project just yet! It’s true that people have stuffed some Linux 2.2 kernel on a single floppy and still had enough space remaining to pull together a somewhat usable system. But Nanolinux can hardly be compared to one of these. You have a Linux 3.0 kernel here – and it features a graphical desktop together with a surprisingly high amount of useful applications!

Applications

Speaking of applications: Most of which are part of XFDOS can be found in Nanolinux, too, like e.g. FlWriter, FlView and Dillo. There are just a few exceptions as well: The DOS media player, PDF viewer etc. However there are also a few programs on board which you don’t know from the graphical DOS distribution. I’m going to concentrate on these.

Showing off the Nanolinux menu

A nice one is the system stats program: As you would expect it gives you an overview of system ressources like CPU and RAM usage. But it does a lot more than that! It also lists running processes, shows your mounts, can display the dmesg – and more. Pretty useful small tool!

Then we have Fluff from TinyCore. It is a minimalist file manager. Don’t start looking for icons or things like that. It follows a text-based approach you may know in form of some console file manager. It’s small but functional and works pretty well once you get used to it.

System stats and the Fluff file manager

Want to communicate with others on the net? Not a problem for Nanolinux. While it comes with Dillo, this browser is not really capable of displaying today’s websites correctly. But Nanolinux also has FlChat – a complete IRC client! So it allows you to talk to people all over the world without much trouble.

FlChat – a FLTK IRC client!

Or perhaps you want to listen to music? In this case you’ve got the choice between two FLTK applications: FlMusic and FlRadio. The former is a CD player and the second let’s you listen to web radio stations. Since Nanolinux runs from RAM after it has started, it is no problem to eject the CD and put in some audio CD of your choice instead.

FlMusic and FlRadio for your ears

Extensions

Even though that’s a pretty formidable collections of programs, there’s of course always the point where you need something Nanolinux does not provide. Like it’s mother, TinyCore, Nanolinux supports Extensions in this case. These are binary packages which can add pre-build applications to your system.

Let’s imagine you want to burn a CD. Nanolinux has an extension for FlBurn available. After clicking on it from the extension list, the system downloads and installs the extension. Once this is finished, FlBurn will be available on the system.

FlBurn installed from the extensions

There are a few extensions available for you. And what to do if you need a program that has not been packaged for Nanolinux? Well, you can always try to build it yourself. If you feel like it, there’s the compile_nl package for you which provides what you need.

Don’t be too ambitious however! Nanolinux comes with Nano-X, remember? That means any program which depends on some Xorg library won’t compile on your system. You’ll just end up with an error message like the one shown in the screenshot below!

Compiling your own packages with “compile_nl”

Summary

Nanolinux builds upon the core of the TinyCore Linux distribution – and while it remains below the ordinary TinyCore in size, it comes with many useful applications by default. It can run on a system with as little as 64 MB of RAM and is extensible if you need any programs which did not fit into the 14 MB iso image.

This little distribution can do that thanks to the use of Nano-X (think X11’s little brother) and a special version of the FLTK toolkit modified to cope with that slim windowing system. It is definitely worth a try if you’re at all into the world of minimalism. And even if you’re not – it can be a nice playing around just to see what is possible.

What’s next?

While I do have something in mind which would be fitting after this post, I’m not completely sure that I’ll manage to get it done within the remaining time of this year. Just wait and see!

GTK-based applications #1: Terminal emulators summary (3/3)

Here’s the summary of the GTK terminal emulator test. It provides four tables for easier comparison of the results.

Overall Ranking

I’ll begin with the overall rating here since that’s the most important thing. I’ve compared all DEs 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. So, here’s the result:

Rank DE Version
01 Lwt 20130625
02 Mt .1
03 Lilyterm 0.9.9.2
04 Ftjerm 0.12.3
05 MLTerm 3.2.0
06 Stjerm 0.16_19
07 Tinyterm svn-20100223
08*) Lxterminal 0.1.11
09 QuTerm 0.1
09 Tilda git-20130625
10 vTerminal 13
11 Sakura 3.0.4
12 Evilvte 0.5.1
12 Termite 6
12 Xfce4-Terminal 0.6.2
13 ROXTerm 2.7.2
14 Gnome-Terminal 3.8.3
15 Dwt 0.3

*) Needed disk space not measured for Lxterminal

RAM usage

Here’s the table that compares memory usage of the tested terminal emulators:

<110 MB 110 – 115 MB 116 – 120 MB >120 MB
Rank DE Version Memory usage
01 Lwt 20130625 106 MB
01 MLTerm 3.2.0 106 MB
02 Lilyterm 0.9.9.2 107 MB
02 Tilda git-20130625 107 MB
03 Lxterminal 0.1.11 108 MB
03 Mt .1 108 MB
03 Stjerm 0.16_19 108 MB
04 Ftjerm 0.12.3 109 MB
04 QuTerm 0.1 109 MB
04 Tinyterm svn-20100223 109 MB
05 Termite 6 113 MB
05 vTerminal 13 113 MB
06 Sakura 3.0.4 114 MB
07 Evilvte 0.5.1 115 MB
08 ROXTerm 2.7.2 117 MB
08 Xfce4-Terminal 0.6.2 117 MB
09 Dwt 0.3 120 MB
10 Gnome Terminal 3.8.3 121 MB

Drive space needed

Here’s the next table:

<5 MB 5 – 10 MB 11 – 100 MB >100 MB
Rank DE Version Disk space used
00 Lxterminal 0.1.11 not measured
01 Lwt 20130625 +4.6 MB
01 Ftjerm 0.12.3 +4.6 MB
02 Lilyterm 0.9.9.2 +5.3 MB
03 Mt .1 +8.0 MB
04 Tinyterm svn-20100223 +12 MB
04 Stjerm 0.16_19 +12 MB
05 Tilda git-20130625 +13 MB
05 QuTerm 0.1 +13 MB
05 vTerminal 13 +13 MB
06 Xfce4-Terminal 0.6.2 +17 MB
07 Evilvte 0.5.1 +104 MB
08 Sakura 3.0.4 +109 MB
09 Gnome-terminal 3.8.3 +111 MB
09 Termite 6 +111 MB
10 ROXTerm 2.7.2 +113 MB
11 MLTerm 3.2.0 +115 MB
12 Dwt 0.3 +137 MB

Download size

And here’s the last one:

<50 KB 51 – 500 KB 501 KB – 5 MB >5 MB
Rank DE Version size
01 Lwt 20130625 ~4 KB
01 Mt .1 ~4 KB
01 Tinyterm svn-20100223 ~4 KB
02 QuTerm 0.1 ~5 KB
03 Stjerm 0.16_19 ~20 KB
04 Ftjerm 0.12.3 ~25 KB
05 vTerminal 13 ~53 KB
06 Lxterminal 0.1.11 ~70 KB
07 Lilyterm 0.9.9.2 ~160 KB
08 Tilda git-20130625 ~193 KB
09 Xfce-4-Terminal 0.6.2 ~699 KB
10 Evilvte 0.5.1 ~14,6 MB
10 Sakura 3.0.4 ~14,6 MB
11 ROXTerm 2.7.2 ~14,7 MB
12 Termite 6 ~14,9 MB
13 Gnome-terminal 3.8.3 ~15,7 MB
14 Dwt 0.3 ~16,6 MB
14 MLTerm 3.2.0 ~16,6 MB

Conclusion

The range of needed RAM on startup is not very large. Still on machines which have little memory available it makes a huge difference if the system with LXDE and a terminal emulator on top of it needs 106 MB or 121 MB of RAM! The range of drive space needed is a lot larger. Here it’s primarily GTK2 applications vs. GTK3 ones. Same thing for the download size: GTK3 brings in a few dependencies which means there’s quite a bit more to download.

What’s next?

The post will begin with a GTK+ file manager test.

GTK-based applications #1: Terminal emulators (2/3)

Here’s the second part of the GTK terminal emulators test. It’s N – Z today. Again we have 9 terminal emulators to take a look at.

The candidates

Here are the candidates:

(Again: Since there’s a lot of them out there, I may well have missed some interesting ones. Feel free to tell me in this case!)

Not tested

Last time I forgot to mention 3 more terminal emulators which don’t run on my test system:

(If you happen to get any of these to work on Arch and care to tell me, I’d be happy for any comments.)

Testing system

The testing system was the same that I described in my previous post.

QuTerm

QuTerm is a Quake-style terminal emulator which uses GTK2.

LXDE with QuTerm

Installation

pacman -U quterm-0.1-1-i686.pkg.tar.xz (4868 / 5 KB)

Statistics

Memory usage after starting up LXDE and opening QuTerm 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 LXDE QuTerm 0.1
MemTotal: 3625888 kb
MemFree: 3514496 kb
Buffers: 10508 kb
Cached: 61876 kb
Rootfs: 830984 / 812 MB
RAM used at startup: 111392 / ~109 MB
Disk space (less LXDE system): 13504 / ~13 MB

ROXTerm

ROXTerm is a terminal emulator which uses GTK3.

LXDE with ROXTerm

Installation

pacman -S roxterm (230084 / 230 KB + 13 dependencies: 14899200 / 14,9 MB)

Statistics

Memory usage after starting up LXDE and opening ROXTerm 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 LXDE ROXTerm 2.7.2
MemTotal: 3625888 kb
MemFree: 3506020 kb
Buffers: 10552 kb
Cached: 68612 kb
Rootfs: 933296 / 912 MB
RAM used at startup: 119868 / ~117 MB
Disk space (less LXDE system): 115816 / ~113 MB

Sakura

Sakura is a terminal emulator which uses GTK3.

LXDE with Sakura

Installation

pacman -S sakura (40416 / 40 KB + 12 deps: 14899200 / 14,9 MB)

Statistics

Memory usage after starting up LXDE and opening Sakura 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 LXDE Sakura 3.0.4
MemTotal: 3625888 kb
MemFree: 3508796 kb
Buffers: 10204 kb
Cached: 68288 kb
Rootfs: 929500 / 908 MB
RAM used at startup: 117092 / ~114 MB
Disk space (less LXDE system): 112020 / ~109 MB

Stjerm

Stjerm is a Quake-style terminal emulator which uses GTK2.

LXDE with Stjerm

Installation

pacman -U stjerm-git-0.16_19_g4038b07-1-i686.pkg.tar.xz (19564 / 20 KB)

Statistics

Memory usage after starting up LXDE and opening Stjerm via run (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 LXDE Stjerm 0.16_19
MemTotal: 3625888 kb
MemFree: 3515092 kb
Buffers: 10552 kb
Cached: 61552 kb
Rootfs: 829620 / 811 MB
RAM used at startup: 110796 / ~108 MB
Disk space (less LXDE system): 12140 / ~12 MB

Termite

Termite is a terminal emulator which uses GTK3.

LXDE with Termite

Installation

pacman -U vte3-select-text-0.34.6-1-i686.pkg.tar.xz (356904 / 357 KB 12 dep: 14899200 / 14,9 MB)
pacman -U termite-6-1-i686.pkg.tar.xz (19520 / 20 KB)

Statistics

Memory usage after starting up LXDE and opening Termite 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 LXDE Termite 6
MemTotal: 3625888 kb
MemFree: 3510272 kb
Buffers: 10220 kb
Cached: 67108 kb
Rootfs: 931076 / 910 MB
RAM used at startup: 115616 / ~113 MB
Disk space (less LXDE system): 113596 / ~111 MB

Tilda

Tilda is Quake-style a terminal emulator which uses GTK2.

LXDE with Tilda

Installation

pacman -U tilda-git-20130625-2-i686.pkg.tar.xz (64824 / 65 KB + 2 deps: 133120 / 133 KB)

Statistics

Memory usage after starting up LXDE and opening Tilda 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 LXDE Tilda git-20130625
MemTotal: 3625888 kb
MemFree: 3516252 kb
Buffers: 9800 kb
Cached: 62824 kb
Rootfs: 830976 / 812 MB
RAM used at startup: 109636 / ~107 MB
Disk space (less LXDE system): 13496 / ~13 MB

Tinyterm

Tinyterm is a terminal emulator which uses GTK2.

LXDE with Tinyterm

Installation

pacman -U tinyterm-svn-20100223-1-i686.pkg.tar.xz (4180 / 4 KB)

Statistics

Memory usage after starting up LXDE and opening Tinyterm via run (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 LXDE Tinyterm svn-20100223
MemTotal: 3625888 kb
MemFree: 3514148 kb
Buffers: 10520 kb
Cached: 62804 kb
Rootfs: 829576 / 811 MB
RAM used at startup: 111740 / ~109 MB
Disk space (less LXDE system): 12096 / ~12 MB

vTerminal

vTerminal is a terminal emulator which uses GTK2.

LXDE with vTerminal

Installation

pacman -U vterminal-13-3-i686.pkg.tar.xz (11988 / 12 KB + 2 deps: 40960 / 41 KB)

Statistics

Memory usage after starting up LXDE and opening vTerminal via run (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 LXDE vTerminal 13
MemTotal: 3625888 kb
MemFree: 3510000 kb
Buffers: 12940 kb
Cached: 62480 kb
Rootfs: 831176 / 812 MB
RAM used at startup: 115888 / ~113 MB
Disk space (less LXDE system): 13696 / ~13 MB

Xfce4-Terminal

Xfce4-Terminal is a terminal emulator which uses GTK2.

LXDE with Xfce4-Terminal

Installation

pacman -S xfce4-terminal (300188 / 300 KB + 4 deps: 399360 / 399 KB)

Statistics

Memory usage after starting up LXDE and opening Xfce4-Terminal 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 LXDE Xfce4-Term 0.6.2
MemTotal: 3625888 kb
MemFree: 3505716 kb
Buffers: 11160 kb
Cached: 63488 kb
Rootfs: 835304 / 816 MB
RAM used at startup: 120172 / ~117 MB
Disk space (less LXDE system): 17824 / ~17 MB

What’s next?

The next post will be a summary of the GTK terminal tests and provide a table for easy comparison.

[Update (08/10): Corrected Termite’s disk usage values – copied the wrong ones before.]

GTK-based applications #1: Terminal emulators (1/3)

Today we’re in for taking a look at the various terminal emulators out there which are based on GTK+. This first part deals with the ones which start with A to M.

The candidates

Here’s the list of available GTK+ terminals I got working on Arch:

(Since there’s a lot of them out there, I may well have missed some interesting ones. Feel free to tell me in this case!)

Not tested

Here’s the list of GTK-based terminal emulators which I didn’t test because they didn’t work (since there are so many available I didn’t have much time to mess with these here):

(If you happen to get any of these to work on Arch and care to tell me, I’d be happy for any comments.)

Testing system

For the coming tests I set up a new, clean Arch VM (25.06.2013). The basic system looks like this (after cleaning pacman cache):

Arch Linux “base”
MemTotal: 3625888 kb
MemFree: 3586228 kb
Buffers: 5404 kb
Cached: 18556 kb
Rootfs: 488660 / 478 MB
RAM used at startup: 39660 / ~39 MB

Then I installed a typical LXDE:

pacman -S xorg-server xorg-xinit xf86-video-vesa lxde (132 packages; size: 59914 Bytes / 59 MB)

Memory usage right after starting up LXDE (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 + LXDE (0.5.5)
MemTotal: 3625888 kb
MemFree: 3522368 kb
Buffers: 9740 kb
Cached: 58860 kb
Rootfs: 817480 / 799 MB
RAM used at startup: 103520 / ~101 MB
Disk space (less basic system): 328820 / ~321 MB

Dwt

DWT is a terminal emulator which uses GTK3.

LXDE with dwt

Installation

pacman -U dwt-0.3-1-i686.pkg.tar.xz (7272 / 7 KB + 19 dependencies: 1689000 KB / 17 MB)

Statistics

Memory usage after starting up LXDE and opening Dwt 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 LXDE dwt 0.3
MemTotal: 3625888 kb
MemFree: 3502520 kb
Buffers: 11648 kb
Cached: 67740 kb
Rootfs: 958252 / 936 MB
RAM used at startup: 123368 / ~120 MB
Disk space (less LXDE system): 140772 / ~137 MB

Evilvte

Evilvte is a terminal emulator which uses GTK3.

LXDE with Evilvte

Installation

pacman -U evilvte-0.5.1-1-i686.pkg.tar.xz (28244 / 28 KB + 13 deps: 14899200 / 15 M)

Statistics

Memory usage after starting up LXDE and opening Evilvte 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 LXDE Evilvte 0.5.1
MemTotal: 3625888 kb
MemFree: 3508236 kb
Buffers: 10292 kb
Cached: 68140 kb
Rootfs: 923508 / 902 MB
RAM used at startup: 117652 / ~115 MB
Disk space (less LXDE system): 106028 / ~104 MB

Ftjerm

Ftjerm is a terminal emulator which uses GTK2.

LXDE with Ftjerm

Installation

pacman -U ftjerm-0.12.3-1-i686.pkg.tar.xz (24968 / 25 KB)

Statistics

Memory usage after starting up LXDE and opening Ftjerm via run from 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 LXDE Ftjerm 0.12.3
MemTotal: 3625888 kb
MemFree: 3514480 kb
Buffers: 10556 kb
Cached: 62180 kb
Rootfs: 822280 / 804 MB
RAM used at startup: 111408 / ~109 MB
Disk space (less LXDE system): 4800 / ~4.6 MB

Gnome-terminal

The gnome-terminal is a terminal emulator which uses GTK3.

LXDE with Gnome-terminal

Installation

pacman -S gnome-terminal (16056320 / 16 MB)

Statistics

Memory usage after starting up LXDE and opening Gnome-terminal 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 LXDE Gnome-terminal 3.8.3
MemTotal: 3625888 kb
MemFree: 3501640 kb
Buffers: 12000 kb
Cached: 69792 kb
Rootfs: 931004 / 910 MB
RAM used at startup: 124248 / ~121 MB
Disk space (less LXDE system): 113524 / ~111 MB

Lilyterm

Lilyterm is a terminal emulator which uses GTK2.

LXDE with Lilyterm

Installation

pacman -S lilyterm (163840 / 160 KB)

Statistics

Memory usage after starting up LXDE and opening Lilyterm 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 LXDE Lilyterm 0.9.9.2
MemTotal: 3625888 kb
MemFree: 3516284 kb
Buffers: 9748 kb
Cached: 62648 kb
Rootfs: 822928 / 804 MB
RAM used at startup: 109604 / ~107 MB
Disk space (less LXDE system): 5448 / ~5.3 MB

Lwt

Lwt is a terminal emulator which uses GTK2.

LXDE with Lwt

Installation

pacman -S lwt-20130625-1-i686.pkg.tar.xz (4380 / 4 KB)

Statistics

Memory usage after starting up LXDE and opening Lwt 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 LXDE Lwt 20130625
MemTotal: 3625888 kb
MemFree: 3517248 kb
Buffers: 9776 kb
Cached: 62272 kb
Rootfs: 822204 / 803 MB
RAM used at startup: 108640 / ~106 MB
Disk space (less LXDE system): 4724 / ~4.6 MB

Lxterminal

Lxterminal is a terminal emulator which uses GTK2.

LXDE with Lxterminal

Installation

Included with LXDE

Statistics

Memory usage after starting up LXDE and opening Lxterminal 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 LXDE Lxterminal 0.1.11
MemTotal: 3625888 kb
MemFree: 3515556 kb
Buffers: 9728 kb
Cached: 62020 kb
Rootfs: same as LXDE
RAM used at startup: 110332 / ~108 MB

Mlterm

Mlterm is a terminal emulator which uses GTK3.

LXDE with Mlterm

Installation

pacman -U mlterm-3.2.0-1-i686.pkg.tar.xz (622240 / 622 KB + 19 deps: 16404480 / 16 MB)

Statistics

Memory usage after starting up LXDE and opening Mlterm 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 LXDE Mlterm 3.2.0
MemTotal: 3625888 kb
MemFree: 3517600 kb
Buffers: 10120 kb
Cached: 61444 kb
Rootfs: 935600 / 914 MB
RAM used at startup: 108288 / ~106 MB
Disk space (less LXDE system): 118120 / ~115 MB

Mt

Mt is a terminal emulator which uses GTK2.

LXDE with Mt

Installation

pacman -U mt-.1-2-i686.pkg.tar.xz (4260 / 4 KB)

Statistics

Memory usage after starting up LXDE and opening Mt via run from 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 LXDE Mt .1
MemTotal: 3625888 kb
MemFree: 3515324 kb
Buffers: 10504 kb
Cached: 61212 kb
Rootfs: 825676 / 807 MB
RAM used at startup: 110564 / ~108 MB
Disk space (less LXDE system): 8196 / ~8.0 MB

What’s next?

The next post will deal with the rest of the GTK+ terminal emulators which I got running.

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.