BSD, HURD and Arch?

Posted by kraileth

Today we’ll deal with Arch Linux’s principles transferred to other operating systems.

The Arch Way

Arch Linux’s slogan is: A simple, lightweight distribution. There are many people who want an operating system which truly fits their needs – and nothing else. Arch is usually a good choice for them due to its light-weight core system which can easily be expanded in any direction needed.

The Arch Linux logo

Sure, there are quite some other distribution worth considering. Gentoo, of course, which allows for even deeper customization thanks to its mighty USE-flag and portage system! But many people prefer to go without the hassle of compiling everything. This is often when Arch Linux comes in as it provides binary packages. If it has to be even more lightweight, there are a few distributions which are really fairly minimal. Alpine Linux is very interesting in this regard and some others like Damn Small Linux and Puppy come to mind.

In most cases though, Arch Linux is a very good choice. And that shows: This distribution has attracted many users over the years and is in the top 10 of the distrowatch rating. Why that? Probably because people like The Arch Way of putting together a distro.

Other Distros

Apart from classic Arch Linux there are some other Arch-based distribution. For example there’s ArchBang which combines Arch Linux with the OpenBox WM to provide a light-weight desktop upon installation.

The ArchBang logo

Then there’s Manjaro Linux, an Arch-based distribution which provides graphical tools for everything and aims to be beginner-friendly.

The Parabola logo

Others are Parabola, a distro using the fully free Linux-libre kernel, Arch Linux for ARM and ConnochaetOS, a fully free system that supports the i586 architecture.

If you’re interested in more of them, here‘s a list on the Arch Linux wiki.

Other kernels

Actually people seem to like The Arch Way so much that they miss it even when working with a system which is not Linux-based. For that reason some projects have arisen which kind of copy the Arch principles over to other systems!

There are for example ArchHurd and ArchBSD.

ArchHurd

The former is not exactly a new project – it was founded in early 2010. It made a lot of progress in a short time but seemed to have stalled by the end of 2011. There’s no news item on the project site after August of that year and while still new packages were created that also came to a halt about one year later. In the meantime even the wiki had disappeared.

The ArchHurd logo

Fortunately the project isn’t dead and after a while during which it only lived on in mailing list posts, at least the wiki is back again (which actually was the cause that made me write the previous and this post after I discovered it). Currently progress is still very slow which is due to problems with updating glibc. After the new toolchain is built the whole core repository needs to be rebuilt. So there’s enough work to be done there.

The new wiki has a severe spam problem right now. But I’m sure that can be taken care of sooner or later. And the most important thing is surely that the project is still alive!

ArchBSD

The other project is still very new. While the idea exited for a while, the site for it was put up in January 2013. ArchBSD is progressing nicely and considering the short time it exists, it already got pretty far in bringing the familiar Arch feeling to an OS using the FreeBSD kernel!

The Arch BSD logo

Right now it’s far to early to say whether this blend is to survive on the long run or not. Currently it looks good with quite some development taking place. And compared to ArchHurd it also has much newer packages in general (which however is no wonder since it started with later ones).

What’s next?

In the next post I’ll take a brief look at ArchHurd and ArchBSD.

A look beyond the Linux teacup – Unix-likes

Posted by kraileth

Yes, I know. I said that I’d play with a new version of the DDD when I wrote the previous entry. Well, I did. Actually I made some nice progress on it, too. However there’s one little issue which ruined the whole thing for me: A new version of the tool which I use to build the live-image (ArchISO). The ability to produce isos for just one architecture (i686 in my case) was dropped and now it can only build dual isos – which are of course twice as big! I found a patch but still could not get things working. For that reason I decided to postpone it.

For quite a while I’ve been interested in things that lie just a few meters behind die Linux “border”: Other Unix-like systems. And just recently I made some discoveries – two of which I’ll cover with the next post and a third one which may be the topic to the one thereafter. But first let’s discuss a few basics.

Attractiveness of Linux

We live in very interesting times when it comes to operating systems: The quasi-monopoly of Microsoft’s Windows for home PCs is taking severe blows. No, I don’t want to predict that they are done for. On the opposite: I think that they will manage to hold extremely high market shares for quite a while in the future. And I also don’t want to talk about mistakes of Microsoft (like Vista or 8′s “Metro”/”NewUI”).

What does really shake the monopoly is the fact that Linux is becoming a real alternative. It has been in the server sector for a long time now and for the above-average user in general, too. But now one of the (at least commercially) most important frontiers is crossed: Linux is getting fit for gaming.

That’s why more and more computer users are “giving it a try”. Fortunately there are quite some distros today which require little to no previous Linux knowledge and let you complete the installation without having to know what run levels are or how mount points work. While this can rightly be called a good thing, it does have two sides (like all things do). Linux systems can be extremely convenient these days (just think of the superior package management when combined with some kind of “software center” as Ubuntu has one!). This however bears the risk of a “new generation” of “Linux users” who are content with just having an “easy” and quite stable system.

Unix-likes

It’s those people who didn’t really get that technically the term “Linux” refers to the kernel only (a little more on that in a minute). There’s more than one operating system which works somewhat or even very close to how Unix functions. That’s why people talk of a Unix-like system or *nix. Some systems comply with the entire POSIX standard of Unix and some are even certified to be rightfully called Unix. Especially the later however is more of a commercial thing. If you’re new to all this, you’ll be astounded just how many “true” Unices there are – not even to talk about the Unix-likes!

People often distinguish between a certified Unix, functional Unix (the typical Unix-like which tries to emulate the functions provided by Unix) and a genetic Unix (which derived from the source code of a Unix system).

Just like noted before, there are quite some members of the large family of Unix-likes. Just a few examples:

BSD
Linux
Mac OS X
Minix
NeXTSTEP
Solaris
SunOS
System V
Xenix

Some of these can actually be regarded as sub-categories. For example there are several BSDs which derived from 386BSD:

NetBSD
FreeBSD
OpenBSD
DragonFly BSD

Kernel

What’s a kernel? Think of it as the “core” of your OS if you’re not yet familiar with that term. The kernel is what really interacts with the actual hardware. The before-mentioned superficial Linux user may not care (or even know it), but strictly speaking Linux means the kernel only and thus refers to an operating system component rather than an entire OS. Usually “Linux distributions” pack together the Linux kernel and the GNU operating system basis (plus some or even a lot of other applications).

It’s important to know of the two different areas in system memory: Kernel space and user space. Why is that relevant? Simply because without it you won’t understand the difference in kernel design. The kernel is almighty (and has to be) while the applications running in user space can also be run underprivileged (and thus can’t do harm to your system). People typically distinguish between the kernel and the userland (the programs running in user space).

There are different approaches when it comes to classify a kernel. Linux is a so-called monolithic kernel which means that it’s “one big thing”. Most of the important things low-level things are handled by the kernel. Linux is modular, though. It can load and unload kernel modules (like drivers) while running without having to restart the system. Another idea is that of a micro kernel (e.g. Minix). Here the kernel is only doing the most basic stuff and everything else is provided by user space programs.

What’s next?

For people who don’t stop with a just working system and instead like to dig a little deeper there are some other playgrounds besides Linux-based systems. As collected above, there’s a great many of other Unix-like systems which use another kernel and a (sometimes slightly) different userland. The next blog entry will present two of them: BSD and HURD.

Situation of the Linux Desktop #2: Habemus tumultum…

Posted by kraileth

… 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)

Posted by kraileth

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)

Posted by kraileth

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:

GoodWord (Doesn’t include any kind of readme and I have no clue how to compile it.)
Freddy (Qt3 based.)
QMWedit (Qt3 based.)
qPEditor (Won’t compile.)
QWriter (Won’t compile.)
TextRoom (Won’t compile.)

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)

Posted by kraileth

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)

Posted by kraileth

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):

Andromeda / Homepage
Dfilebrowser / Homepage
Dino / Homepage
Dolphin / Homepage
Hamsi Manager / Homepage
NewBreeze / Homepage
qtFM / Homepage
ScOpe (No homepage)

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

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.

May 2013
M	T	W	T	F	S	S
« Apr
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31