>> * longer history for bash: that should be the default; you can not extend the
>> history once you do not find something in the history any more.
> We use Zsh as default and its HISTSIZE is 500 by default for the live system,
> this should be enough (if it's not we can discuss it).
  It in deed is; I just forgot that I was working with zsh rather than bash
where it always displays the whole history on 'history<cr>'. zsh works
with 'history 1<cr>' well though.
>> * no network services running on startup: It is often necessary to operate a
>> rescue console in an unsafe environment: things like NetowrkManager, dhclient,
>> avahi-daemon, rpc* should only be started with explicit consent by the user or
>> if the user gives a boot option such as 'with networking'
> We start by default what's considered to be important for our target audience.
> E.g. there's no point in not starting dhcp by default for the usual scenarios
> Grml is used in. If you don't want to start dhcp you can easily turn it off by
> using the nodhcp boot option.
>
> What we *could* discuss though is whether it would make sense to make startup of
> rpcbind/rpb.statd and avahi-daemon more controllable (though we never had a
> single user requesting this since a long time, so I'm wondering whether it's
> really such an issue?). Any opinions on that?
Why not give it an additional boot option (alltogether not only nodhcp) and
add that option to the default boot menu? This is an important use case.
I have seen that you have so many boot options; why not add one called
'without networking' and/or 'with manual network setup only'. The reason
why nobody asked for it may be that there are plenty of other rescue-
CDs that comply with the intent of starting no network services by default.
Remember that turning off services may not be possible if the wlan
interface is turned on by default.

>
>> * gpg keys of all major distributions should be included in order to be able to
>> verify downloads made via GRML. A similar issue has already been posted for the
>> System Rescue CD: http://www.sysresccd.org/forums/viewtopic.php?f=6&t=5208
> I don't plan to maintain such a list on my own and don't see the point in
> shipping that through our ISO, that's something the user should care about on
> their own IMHO.
I see your point that there will be some overhead in managing such a list.
However I believe you did not consider my considerations about it yet:
If you only have an untrusted internet connection (and we all have) then
we need some way to fetch the keys via another more trusted medium.
Doing this by telephone would not be good either because also telephone
calls can be re-routed. The only viable way to obtain such keys trustedly
basically is to obtain them anonymously because then an intelligence
agency or whoever would like to attack us would have to change this for
all users. If they did it then the manipulation would become public
knowledge shortly because there will always be some people who test it
against the downloaded keys and they can not manipulate connections
for all of them. Do you see the point in having this demand?
I believe you will. - A shop purchased DVD including GRML will be 100%
safe following this argumentation while simply downloading something
is known to be 100% unsafe these days.


> _____________________________________
> GRML issue tracker <bts@bts.grml.org>
> <http://bts.grml.org/grml/issue1326>
> _____________________________________
>