I also have a valid usecase. (Maybe not one that grml targets.)
I used grml on my thinkpad x40 for a year when its expensive and special HDD died. It served me quite well. I also created a remastered version with the newest firefox and ubuntu repo chromium on it.
What am I saying is that with these tools in question already available it was (not perfect, but) quite usable.
When I left my pendrive in my friends car who gave me a lift to debconf11 I tried grml-live to streamline the bootprocess for a brand new grml and it also worked quite well.
So when I am talking about a tool I am also thinking about grml as an educational tool, survive sysadmin minimal desktop and learning/experimenting/development environment. (Which all can be invalid from another point of view.)
On Wed, Dec 28, 2011 at 01:56:57PM +0100, Michael Prokop wrote:
- Csillag Tamas [Wed Dec 28, 2011 at 11:08:29AM +0100]:
comgt (180k)
Thanks, re-added already: http://git.io/rtTeQg
Thanks.
libnet-*-perl
They used to be dependencies of other packages that aren't available any longer. Is there any specific package that's considered relevant for install and rescue?
ok, I understand. Maybe this is not that important. I agree.
mutt postfix (I was using this for educating mailing basics also good for testing)
In an friendly evironment it is easy to mail with postfix and mutt. replying to another mail in this thread: If your mail is available on an imap server a stock mutt config is enought for sending/receiving mails, a bit tweaking in postfix can be necessary.
runit (520k)
What's the benefit for the live system?
I find many of its tools valuable. Like setting up (mini) services for replicating data to other machines on the network (along with ipsvd).
rxvt-unicode (this was part or the release from the begining)
xterm is there and should be enough for install and rescue mission, IMO
rxvt-unicode is quite small, much more flexible and resource friendly than xterm.
What kind of testing is needed to get (most/some of) the tools back on the cd?
Testing is very important, yes. But it's not just testing but also:
taking care of failing builds (we provide daily builds at http://grml.org/daily/ and trigger ISO builds with each git commit)
integrating packages into Grml tools (grml-quickconfig, grml-x,...), window manager, providing sane default configs,...
I think most of the tools we are talking about either do not need configuration or the default is ok. grml-* tools are ok. For tools already there in 2011.05 maybe not a must-have.
- taking care of bugs (see http://bts.grml.org/grml/) and user support ("why doesn't foo work?")
I think most of the package related bugs is a valid debian bug also. So it could make sense to forward to the debian bts.
Thanks for your feedback, we highly appreciate that.
Thanks for your encouragement.
[1] Thanks for the list. We will review and discuss your software selection in further detail, promised.
regards, -mika-
Regards, cstamas