We believe that your issue has been closed by the upload of
Version 0.12.3 of grml-live from Michael Prokop <mika@grml.org>.
The explanation is attached below

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Wed, 15 Dec 2010 16:11:27 +0100
Source: grml-live
Binary: grml-live grml-live-addons grml-live-db grml-live-buildd
Architecture: source all
Version: 0.12.3
Distribution: unstable
Urgency: low
Maintainer: Michael Prokop <mika@grml.org>
Changed-By: Michael Prokop <mika@grml.org>
Description: 
 grml-live  - build system for creating a Grml (based) Linux live system
 grml-live-addons - templates/boot/addons for grml-live
 grml-live-buildd - autobuild daemon for grml-live
 grml-live-db - log package build information of grml-live to database
Changes: 
 grml-live (0.12.3) unstable; urgency=low
 .
   The "let's clean the floor" release.
 .
   * Bugfix:
     - [7bbfd24] Rework apt.conf handling in instsoft/updatebase (provide
       /etc/apt/apt.conf.d/15grml-live), drop /etc/kernel-img.conf support.
       The reworked apt.conf handling addresses the issue that with usage of
       BASE.tgz there might result packages from recommends in the ISO (like
       for example iso-codes via python-apt).
 .
   * Package list changes:
     - [5476dee] replace perf with linux-tools-2.6.36 package in GRMLBASE.
     - [ae6845f] Update package list in NFSROOT (grub->grub-pc, live-
       initramfs->live-boot, drop cvs/subversion/jove/subversion, disable
       cfengine2/libapt-pkg-perl).
 .
   * Get rid of window managers from GRML_FULL that are either too large,
     unconfigured, unused,... - see issue897 for the discussion.
     [Closes: issue897]
     - [a4907de] Remove fvwm
     - [a68ff37] Remove ratpoison and ratmenu
     - [c44b1e3] Remove dwm and dwm-tools
     - [5eb0e90] Remove twm
     - [0a17b3c] Remove w9wm
     - [69ca260] Remove evilwm
     - [9df6db8] Remove jwm
     - [d077db1] Remove pekwm
 .
   * Removals from GRML_FULL package list:
     - [b88d7b5] Remove ysm (orphaned, see #595398).
     - [50bc2fe] Remove emcast (orphaned, see #594619).
     - [0040aec] Remove cdrbq (orphaned, see #602587).
     - [0bcc921] Remove wyrd (not relevant enough).
     - [372cd2d] Remove xaw3dg (not relevant enough).
     - [07d1e00] Remove yaird (initramfs-tools is the
       recommended and supported i-t generator).
     - [f8990f6] Remove pdns* packages (except for pdns-recursor).
     - [e601ea1] Remove nedit (too large for too many already
       existing editors).
     - [c402efd] Remove mrxvt[-common] from GRML_FULL.
     - [13c5b0b] Remove zlib1g (library -> rdepends).
     - [67cfcf5] Remove gq (unmaintained/dead, see #593165).
     - [bed9733] Remove cdda2wav + cdrecord from GRML_FULL (unavailable).
     - [57280bf] Remove geresh (dead/unmaintained, see #595478).
     - [e240523] Remove dietlibc (dietlibc-dev is the relevant package).
     - [09ec6b0] Remove dumputils (orphaned upstream, see #466870).
     - [d8e5c2d] Remove cbrowser (dead upstream, see #595987).
     - [2a296ca] Remove dpkg-multicd (unavailable, merged into
       dselect, see #557063).
     - [a4b7699] Remove dpkg-ftp (unavailable, merged into
       dselect, see #557062).
     - [6537f9e] Remove tcl8.3 (unavailable, tcl8.4 is there).
     - [ed0a6ab] Remove jikes (orphaned, see #508366).
     - [72eff19] Remove metamail (orphaned, see #274451).
     - [ebfec95] Remove mkisofs (unavailable).
     - [847ba32] Remove python-celementtree + python-elementtree
       (unavailable + only useful with python < 2.5, see #564377).
     - [547476e] Remove realtime-lsm (deprecated, see #499245).
     - [266c05b] Remove nictools-nopci (i386-only).
     - [73bfef1] Remove star (unavailable).
     - [bbfde64] Remove starttls (dead, see #587264).
     - [4d62e55] Remove swapd (dead, see #595091).
     - [a20335f] Remove webcpp (abandoned upstream, see #547528).
     - [6ca58fa] Remove xvncviewer (unavailable).
     - [2fc6daf] Move zfs-fuse from Grml packages to Debian packages.
     - [a317c5c] Remove speechd-up (i386-only, espeakup replaces it).
     - [d9d3706] Remove abs-guide (not important enough)
     - [c4c9c35] Remove uswsusp (has issues in older Debian
       releases, should not be too relevant for Grml).
     - [2e7c1fb] Remove ike-scan (4MB is too much)
     - [a01048a] Remove hasciicam (out-of-scope).
     - [6b5262f] Remove gocr (out-of-scope).
     - [33578dc] Remove hal (out-of-scope).
     - [962a5cb] Remove hal-info (out-of-scope).
     - [7a1b346] Remove fusesmb (out-of-scope).
     - [ca8f465] Remove icecast2 (out-of-scope).
     - [05cfbd2] Remove moosic (out-of-scope).
     - [4774440] Remove mp3blaster (out-of-scope).
     - [5baa139] Remove mplayer-skin-blue (out-of-scope).
     - [3806828] Remove lkl (orphaned, see #553307).
Checksums-Sha1: 
 13d12a5a218e943fea96a649b74484384c7e2b8e 951 grml-live_0.12.3.dsc
 4b9b975b868d965fbd45e4d035b23f4c1e6f1861 8656024 grml-live_0.12.3.tar.gz
 8179e73c72e0b4f7598abf9db6384b27d61ad5ba 1334670 grml-live_0.12.3_all.deb
 e049d92933bd34a51cda28cf3d74a5a6478604e3 7364014 grml-live-addons_0.12.3_all.deb
 16aa70725c71618aec67e2d2314d61832a87991f 46110 grml-live-db_0.12.3_all.deb
 ff3169a569a6c3b758687286c188e39649495b63 41672 grml-live-buildd_0.12.3_all.deb
Checksums-Sha256: 
 c7fb2b85cfeac9b027b15fa5eb8d4c284f2774a87261b120f542c24bfdc26138 951 grml-live_0.12.3.dsc
 dfe35c1844d7a2669583371590fe8674eb6f600a6e5a457984e093538a334d45 8656024 grml-live_0.12.3.tar.gz
 d5584d81f67d2ce92a1923d271807fe1d88370af2bd6184cfb2c8073485d0f98 1334670 grml-live_0.12.3_all.deb
 6295563ccae802a7863b69b6dff505ac96dc4c2ebd7625723ec68a50a608beda 7364014 grml-live-addons_0.12.3_all.deb
 c421720f2c799f620896a4e234a135937b236ba5dcc87fd81047f0107ea26263 46110 grml-live-db_0.12.3_all.deb
 f35bcc67b3b59aa1b462882e79d71ae0b050b045f332dcc09bb738da34b3362e 41672 grml-live-buildd_0.12.3_all.deb
Files: 
 e3bcb3bb307c66105ffc29922d0b610d 951 grml extra grml-live_0.12.3.dsc
 55702b5eff242d9e85e29749ccf3073e 8656024 grml extra grml-live_0.12.3.tar.gz
 b25ce62704ed996280546918598383bb 1334670 grml extra grml-live_0.12.3_all.deb
 466762a41b1b196e70dd1b7e77eb147a 7364014 grml extra grml-live-addons_0.12.3_all.deb
 349428028bdc1e411802aab4d5389e92 46110 grml extra grml-live-db_0.12.3_all.deb
 4ac2d6d8bb1deca1fa9825d9a4e25904 41672 grml extra grml-live-buildd_0.12.3_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk0I3YwACgkQ2N9T+zficuhwyQCfaW6Uh8OSEqpmDbyqvWv7gjGM
SGUAn3CF3mMo2/6bZ6vayESlFajzIpVi
=ZlQZ
-----END PGP SIGNATURE-----

Ok, thanks for all your input!

IMHO we *should* clean and simplify up our software selection, given the fact 
that our grml-full 64bit ISO has more than 700MB which is a release-stopper as 
well. Something like 10 window managers *are* way too much, given that only few 
of them are even properly configured.

So what I consider for the upcoming stable release is:

Remove (so no longer ship):

* dwm dwm-tools                                                                 
* evilwm
* fvwm*
* jwm
* pekwm
* ratpoison ratmenu
* twm
* w9wm

What stays:

* awesome
* fluxbox [wm-ng]
* openbox
* wmii

If anyone thinks this is not acceptable: please stand up and argument. :)

regards,
-mika-

ft wrote:
"For the record: for me it's the number of wms, that should be reduced,
because there's not much point for a *livecd* to provide such diversity
when the most frequent use is disaster recovery."

Fortunately the grml project _does_ provide structured diversity, for eg
grml-small & medium and the ability to install to disk. Therefore it is
insufficient to quote "the number of wms" per se as reason for their removal --
otherwise you might as well similarly argue to produce only one grml flavour and
not have the install to disk option, have just the one true editor etc.
  Instead you should try a cost-benefit analysis. For eg if the wms all took 1kb
of space you would benefit practically nothing by their removal -- saying the
"number of wms" is the issue without reference to space is illogical.

 Your quoted statement is in fact an argument for _not_ reducing the number of
wms: the person doing the disaster recovery doesn't have to mess around with an
unfamiliar wm or one that frustrates his typical workflow. 

  All the paragraphs in my original post are preceded with "if", please type
"man if" ;)

Regards, Greg

greg wrote:
> If the motivation for removal of window managers is size then it's
> incongruent to remove the lightest such as ratpoison and evilwm.

For the record: for me it's the number of wms, that should be reduced,
because there's not much point for a *livecd* to provide such diversity
when the most frequent use is disaster recovery.

> If the motivation is utility again it's incongruent to remove
> ratpoison : anyone who can use gnu screen (i.e. the grml target user
> base) can use ratpoison (^a --> ^t).  If the motivation is _you_ (a)
> can't use it, (b) can't click a mouse button and have a menu display
> itself, please type "man windowmanager" before starting it.

I know damn well how ratpoison works. And I know damn well how to access
documentation on a unixoid operating system. Thankyouverymuch.

If you look at my initial message, I clearly stated that the default
behaviour didn't work for me at all. And I asserted, that this might be
due to the fact that I tryed the WMs in a virtual machine rather than
really booting my laptop from the live cd.

Also, what I wrote in msg3411 is clearly my personal point of view. For
which I've been *asked*, to get the ball going. I do believe that having
four of five window managers on board is enough for a live cd like
grml. And I stated which I think those should be. And if ratpoison would
be among those in the end, then fine. I wouldn't care, because I usually
don't even bother to start X when I'm using grml.

Regards, Frank

JFTR: ft's issue with not being able to use ratpoison is not a ratpoison issue.
It happens also with awesome: I didn't get any window manager I tried to work
properly in KVM if X was started with grml-x. Starting X with startx worked.

And yes, the compatibility with screen is IMHO a big vote for ratpoison. :-)

Hello. 
 If the motivation for removal of window managers is size then it's incongruent
to remove the lightest such as ratpoison and evilwm.
 If the motivation is utility again it's incongruent to remove ratpoison :
anyone who can use gnu screen (i.e. the grml target user base) can use ratpoison
(^a --> ^t).
 If the motivation is _you_ (a) can't use it, (b) can't click a mouse button and
have a menu display itself, please type "man windowmanager" before starting it. 
  If this issue is resolved by voting (I'd rather have it settled by reason and
consensus) I vote for ratpoison and evilwm.

On Saturday 20 November 2010 01:22:14 you wrote:

> I'd vote to keep awesome over ratpoison, though whatever the result
> of this vote will be we've to make sure the WM work smooth OOTB.

JFTR awesome++ ;0

* Axel Beckert wrote in grml's BTS on 20101120 / 01:16:

> Please keep at least:

> * awesome
> * ratpoison

> grml will be less useful for me without at least one of those two window managers

I'd vote to keep awesome over ratpoison, though whatever the result
of this vote will be we've to make sure the WM work smooth OOTB.

regards,
-mika-

Please keep at least:

* awesome
* ratpoison

grml will be less useful for me without at least one of those two window managers

Despite being a heavy FVWM user, FVWM's usefulness depends a lot on the personal
configuration which does not make much sense on a live CD IMHO.

I know the compression ration depends on the sort of files: So 3.5 as a value is
just an orientation (as this is for the whole grml-cd, it is a very realistic
number) and for calculation purposes only.
Calculating with unknown variable(s) makes no sense :-).

- Sedat -

* Sedat Dilek wrote in grml's BTS on 20101108 / 14:06:

> Thanks ch for providing numbers for the compression-ratio:

> 2.4G        grml_chroot
> -rw-r--r-- 1 root root 698M Nov  7 20:44 grml_isos/grml_0.0.1.iso

> So, this means a ratio of 3.5 : 1.

> If I summarized correctly it's 2.25MB (other WM removals, w/o fvwm packages).

> 2.250 : 3.5 approx 643 [kB]

> That's not much!

> fvwm2 + fvwm2-crystal would save 5.6MB (squashfs-compressed)

> 20.156,8 : 3.5 = 5.759 [kB]

JFTR: You can't assume a fixed ratio of 3.5, it strongly depends of
the type of files that are involved (text compresses much better
than already compressed files). But removal of fvwm* will definetly
save us quite some space, ACK.

regards,
-mika-

> Considered for removal:
> * dwm (would save 180kb)
> * evilwm (would save 94,2kb)
> * fvwm (would save 14,7MB)
> * fvwm2-crystal (would save 5104kb)
> * jwm (would save 299kb)
> * pekwm (would save 1253kb)
> * twm (would save 397kb)
> * w9wm (would save 127kb)

Apart from the fact, that fvwm == fvwm2 (which we briefly discussed on
IRC), I'd agree here, too.

> Further discuss keep/removal of:
> * awesome (would save 2785 + 446kb)
> * rapoison (would save 528kb)
> * wmii (would save 401kb)

[ Calculation reviewed ]

6.510,2 : 3.5 = 1.860 [kB] approx 1.8MB

- Sedat -

Thanks ch for providing numbers for the compression-ratio:

2.4G        grml_chroot
-rw-r--r-- 1 root root 698M Nov  7 20:44 grml_isos/grml_0.0.1.iso

So, this means a ratio of 3.5 : 1.

If I summarized correctly it's 2.25MB (other WM removals, w/o fvwm packages).

2.250 : 3.5 approx 643 [kB]

That's not much!

fvwm2 + fvwm2-crystal would save 5.6MB (squashfs-compressed)

20.156,8 : 3.5 = 5.759 [kB]

- Sedat -

Sedat Dilek wrote:
> Sedat Dilek <sedat.dilek@gmail.com> added the comment:
>
> ACK with... Keep: * fluxbox * openbox * wm-ng
>
> fvwm(2) reminds me my very first window-manager on X... IMHO it can be dropped
> and will save space on FS.

That's not a very convincing reason.

When I tried all the window managers we shipped, with their default
configurations, fvwm and fluxbox felt most usable, with openbox being a
close 2nd. I, for one, wouldn't want to see any of the three go.

Regards, Frank

ACK with... Keep: * fluxbox * openbox * wm-ng

fvwm(2) reminds me my very first window-manager on X... IMHO it can be dropped
and will save space on FS.

But let's wait for users' feedback first.

- Sedat -

Michael Prokop wrote:
> Keep:
> * fluxbox
> * fvwm2
> * openbox
> * wm-ng (is just a simple wrapper script to start fluxbox with gkrellm
> and desktop icons)

ACK.

> Considered for removal:
> * dwm (would save 180kb)
> * evilwm (would save 94,2kb)
> * fvwm (would save 14,7MB)
> * fvwm2-crystal (would save 5104kb)
> * jwm (would save 299kb)
> * pekwm (would save 1253kb)
> * twm (would save 397kb)
> * w9wm (would save 127kb)

Apart from the fact, that fvwm == fvwm2 (which we briefly discussed on
IRC), I'd agree here, too.

> Further discuss keep/removal of:
> * awesome (would save 2785 + 446kb)
> * rapoison (would save 528kb)
> * wmii (would save 401kb)

Well. The only reason, I'd keep one of these is to have a tiling window
manager on board. And I'd definitely go for `awesome' here. The other
two should go.

> Additional decisions to make:
> * wm-ng as default instead of fluxbox?
> * which WM using as default for x-window-manager (wm-ng vs. fluxbox vs. 
> openbox)?

As Christian said, `grml-x' and `x-window-manager' should default to the
same window manager. And I'd agree that it should be `wm-ng' (in the
light of Mika refusing to merge `fluxbox' and `wm-ng' into one :)).

Regards, Frank

Christian Hofstaedtler wrote:
> Christian Hofstaedtler <ch@grml.org> added the comment:
>
> ACK; grml-x and x-window-manager should point to the same wm, let it be wm-ng.

Seconded.
And like I said on IRC, I'd just call what `wm-ng' does `fluxbox'. I
don't think having the two seperated makes much sense. (Like myself, I
didn't *know* what wm-ng was before I tried before writing my wrap-up,
and always wondered, where the desktop items were when I fired up the
fluxbox desktop).

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Regarding the default one, i would choose fluxbox or wm-ng (probably wm-ng as it 
has some desktop icons). Btw. current default wm is openbox.

I would like to keep awesome, it has a sane default config and is imho pretty 
useful per default. The rest can be removed imho :)

ACK; grml-x and x-window-manager should point to the same wm, let it be wm-ng.

Ok, finally found time to closer look into that. My POV:

Keep:
* fluxbox
* fvwm2
* openbox
* wm-ng (is just a simple wrapper script to start fluxbox with gkrellm and 
desktop
icons)

Considered for removal:
* dwm (would save 180kb)
* evilwm (would save 94,2kb)
* fvwm (would save 14,7MB)
* fvwm2-crystal (would save 5104kb)
* jwm (would save 299kb)
* pekwm (would save 1253kb)
* twm (would save 397kb)
* w9wm (would save 127kb)

Further discuss keep/removal of:
* awesome (would save 2785 + 446kb)
* rapoison (would save 528kb)
* wmii (would save 401kb)

Additional decisions to make:
* wm-ng as default instead of fluxbox?
* which WM using as default for x-window-manager (wm-ng vs. fluxbox vs. 
openbox)?

Further opinions?

regards,
-mika-

>> I'd need to check out most of the WMs again, to get a descent proposal
>> for removal.

Okay, let's works this down from the top.

  awesome - I tried it again. It's not as bad as I remembered. But we
            have to think in terms of a live-cd. Does it add anything
            the other WMs don't?  What about its dependencies? What else
            on the isos uses libxcb*? Could this free up a lot of space?
            I'm leaning towards removing this one.

  dwm - Should go. Sorry. But I don't see any value added by this one
        for grml as a live-cd. Does anybody *really* want this WM when
        he's doing desaster recovery? I honestly can't believe that.

  evilwm - When I tried it, it turned the screen black. No mouse pointer
           and the default bindings from the webpage didn't work. This
           was in a `kvm' session. In any case, I'm voting to remove
           this one.

  fluxbox - Finally. This is a default setup you can use. This one
            should definately stay.

  fvwm - Seriously? fwvm1? That's gotta be a joke. And it is. Kind of.
         `fvwm' and `fvwm2' are actually the same. The zsh completion
         for `grml-x' shouldn't list both.

  fvwm2 - This is actually better than I remembered. The menu has the
          whole debian menu, but also a reasonable selection in its own
          submenus. I was about to vote to remove this one, but apart
          from the weird default-fvwm look this is actually very usable.

  fvwm2-crystal - fvwm2 with pretty looks. Couldn't find the big Debian
                  menus, though. The app selection in the windows I
                  could find were quite limited. I'm voting to remove
                  this one.

  jwm - Not bad. But I don't see an advantage over fluxbox or fvwm. I
        think this one is pretty small, so we could keep it. I'm still
        voting to remove it. Why? Because it doesn't earn us any
        functionality.

  openbox - I don't know, but I like this one. The menu is short and
            sweet, but offers the whole Debian menu, too. No bullshit
            user interface... I should probably say "Remove it!" since
            it doesn't add much to fluxbox and fvwm. But this one really
            feels right... Dunno.

  pekwm - Hum. Another small WM. `jwm' felt better and I voted to remove
          it. So, my vote on this one is clear: Remove.

  ratpoison - Another small WM. For mouseless use. So, started it, got a
              black screen. No mouse pointer, makes sense. Didn't
              remember default keybindings. But that's my fault. Looked
              at the projects webpage, which said "C-t c" should open a
              terminal. Didn't work. Useless if we change the default
              keybindings without telling anyone. (again, this is in
              kvm, maybe that has something to do with this problem,
              which is similar to what I saw with evilwm.) Still, I'm
              voting to remove this one.

  twm - X11's default WM. That's all that's positive about this
        one. It's clumsy to use and adds nothing useful. Let's just
        remove it.

  w9wm - A slightly improved 9wm. I don't think we gain anything from
         having this one. At all. Let's remove it.

  wmii - Small tiling WM. The positive aspect is that, when you start
         it, you get a short tutorial displayed. Useful, esp. for users
         who don't know it. Still, this basically helps to start
         terminals. And other WMs to that, too.

  wm-ng - Fluxbox with a desktop and gkrellm. Since it's fluxbox, the
          same as before applies. I'd probably start fluxbox like this
          per default, though.

  x-window-manager - debian-alternatives. Defaults to `openbox'. Not a
                     bad choice.

If I'd be really really strict, I'd say, keep `fluxbox', `fvwm2' and get
rid of the rest. But then, diversity isn't a bad thing. So, I'd also
keep `openbox'. And maybe `wmii' or `awesome' - one of the two
anyway. `awesome' is more powerful but also heavier...

Thinking about it a little more, I'd keep: awesome, fluxbox, fvwm2 and
openbox.

I'd definately remove: -crystal, twm, w9wm, evilwm, ratpoison and dwm.

Undecided about the others, but leaning towards removal.

Regards, Frank

* Frank Terbeck wrote in grml's BTS on 20101026 / 23:51:

> > ACK. Suggestions for removals? (fvwm-crystal is pretty high on my
> > consider-for-removal nowadays.)

> Well, actually, all the ones you can't use out of the box from the
> live-media. 

> I don't have the complete list right now. But last time I tried, awesome
> on the live-cd was pretty damn near useless to me. (Don't get me wrong,
> it's a nice piece of software when you had the time to configure it to
> your taste. But the setup from our last release didn't make it useful at
> all.)

Good point.

> fvwm-crystal should probably go, yes.

> I'd need to check out most of the WMs again, to get a descent proposal
> for removal. But the ones that struck me as usable where, fluxbox and
> openbox (I think).

I think we should come up with a list of WMs (as well as other
software!) we consider for removal and ask our users for feedback.
I justed added that to the todolist for the upcoming developer
meeting, thanks!

regards,
-mika-

Michael Prokop wrote:
>> (Note that I think we're shipping too many X11 window
>> managers, too.)
>
> ACK. Suggestions for removals? (fvwm-crystal is pretty high on my
> consider-for-removal nowadays.)


Well, actually, all the ones you can't use out of the box from the
live-media. 

I don't have the complete list right now. But last time I tried, awesome
on the live-cd was pretty damn near useless to me. (Don't get me wrong,
it's a nice piece of software when you had the time to configure it to
your taste. But the setup from our last release didn't make it useful at
all.)

fvwm-crystal should probably go, yes.

I'd need to check out most of the WMs again, to get a descent proposal
for removal. But the ones that struck me as usable where, fluxbox and
openbox (I think).

Regards, Frank

* Frank Terbeck wrote in grml's BTS on 20101026 / 23:23:

> I agree. We got zsh and mc. We can't possibly ship every file manager
> out there.

ACK

> (Note that I think we're shipping too many X11 window
> managers, too.)

ACK. Suggestions for removals? (fvwm-crystal is pretty high on my
consider-for-removal nowadays.)

> If something solves a certain problem extremely well, we should consider
> it. But that would have to be made clear somewhere.

ACK

regards,
-mika-

Michael Prokop wrote:
> I think we should decide based on their added value: I don't use any file 
> managers on the cmdline on my own, what's the main advantage of the mentioned 
> file managers over let's say for example mc?
>
> We can't just add and add software, our ISOs are oversized already and we need 
> to get them down to 700MB again, that's why I'm quite picky on software 
> additions.

I agree. We got zsh and mc. We can't possibly ship every file manager
out there. (Note that I think we're shipping too many X11 window
managers, too.)

If something solves a certain problem extremely well, we should consider
it. But that would have to be made clear somewhere.

Regards, Frank

Thanks for checking, Christian.

I think we should decide based on their added value: I don't use any file 
managers on the cmdline on my own, what's the main advantage of the mentioned 
file managers over let's say for example mc?

We can't just add and add software, our ISOs are oversized already and we need 
to get them down to 700MB again, that's why I'm quite picky on software 
additions.

regards,
-mika-

Recording current state:
colfm depends on ffi and ffi-ncurses, while only ffi is packaged as libffi-ruby 
in Debian.

vfu is in Debian.

Hi
There is a other fine file column manager called "vfu". That is my
choice.....


2010/8/21 Ulrich Dangel <bts@bts.grml.org>

>
> New submission from Ulrich Dangel <mru@grml.org>:
>
> http://github.com/chneukirchen/colfm seems to be a nice colum file manager
> with
> zsh integration
>
> ----------
> messages: 3334
> nosy: ft, mru
> priority: wish
> status: unread
> title: evaluate inclusion of colm
> topic: grml-etc-core
>
> _____________________________________
> GRML issue tracker <bts@bts.grml.org>
> <http://bts.grml.org/grml/issue897>
> _____________________________________
> _______________________________________________
> Bugs-changes mailing list
> Bugs-changes@ml.grml.org
> http://ml.grml.org/mailman/listinfo/bugs-changes
>

http://github.com/chneukirchen/colfm seems to be a nice colum file manager with 
zsh integration