[Grml-devel] About the new grml direction

[Brad Cable]

I have been running GRML as my main desktop for well over 5 years now,
and I actually welcome their new changes.

The reason for that is that they have developed a great tool,
grml-live, that installs and repackages new ISOs really easily.  Make
sure to get the updated version, though, as I poked quite a few holes
in the one that got released with 2011.12.

I'm now currently running on a 800 MB image that has GRML_XL as well
as additional packages that I personally want, which makes it even
more flexible than it was before.

Granted, it's a little silly that you have to use this repackaging
tool to get a 700 MB ISO, but that can be tricky if trying to get the
exact size right with a certain amount of packages.

Because I use this environment all the time, I would be willing to
step up and control GRML_XL, at least from time to time update it.
I've already reported a few changes (remove ccrypt, hotkey-setup,
sslscan, zoidberg), but GRML_XL will work with their new grml-live,
and it should be ~700 MB.

I can't promise the quality, though, if I were to manage it.  I don't
really keep up to date with new Debian packages so if I were to do
this I would need a bunch of people telling me what they want on it.
I also have a ton on my plate, but releasing twice a year isn't so
bad.

Just some thoughts.

-Brad


On Tue, Dec 27, 2011 at 07:43:06PM +0100, Ulrich Dangel wrote:
> * Alexander Wirt wrote [27.12.11 16:45]:
> > For me grml was always an all purpose live cd for text users and zsh addicts.
> > I always knew I could just load a grml a I would have a more or less complete working
> > environment afterwards. 
> 
> The problem is we don't have the manpower to do such a release. It was
> always cumbersome and stressfull for the persons involved in the
> release.
> 
> And the complete work environment was always a problem. Several times
> questions like these came up:
> 
> Q: Does package X make sense on a Live-CD? 
> A: No but people may using Grml as a Dekstop system/work environment… 
> 
> For me personally it was always unclear what the purpose of Grml was,
> what's its vision, what belongs on the CD, what does not. And i think
> with this release it became clear and obvious.
> 
> > On the other hand I was able to just use grml-small
> > if I needed a live cd just for booting and chrooting into the usual
> > environment (i.e. for restoring the bootloader) or use -small as a base for
> > my own customisations.
>  
> Releasing all different kind of flavours like
> grml-{full,medium,small}{64,32} resulted in six isos, which all had to be
> tested. And again there were typically not many people involved in
> testing the releases.
> It was neither fun nor interesting nor rewarding.  It was just a lot of
> work for nothing really important. And this is not something new.
> 
> And what is the reason for using grml-small instead of the new
> grml-full? USB sticks typically have more then 350mb, if you want to use
> the ISO image on /boot in combination with grml-rescueboot you can mount
> a LVM LV over /boot/grml and use that.
> 
> That being said, i think that we maybe should/can reintroducde
> grml-small. Removing packages from a package list should result in less
> problems than adding new ones. But first we must get rid of grml-small
> specific hacks (IMHO).
> 
> > Unfortunatly these assumptions aren't valid anymore. IMHO it is not a good
> > idea to focus on rescue environments. GRML was known for two things: the
> > great collection of well prepared text tools and their release names. 
> 
> If you look around the internet about discussions for rescue
> systems, network stuff or other Live-CDs, Grml was never recommended as
> the first Distribution. Typically only one persons in the threads
> writing Oh but i like Grml. Thats it. And i personally think it is
> because Grml was everything and nothing. No area it was especially good
> at but tried to please everyone.
> 
> > I don't think focussing on release names as the only unique feature is
> > a good idea.  There are rescue systems like ten a penny.
>  
> That's the reason I wrote
> http://blog.grml.org/archives/369-10-reasons-why-you-should-use-Grml-instead-of.html
> 
> And it is not only rescue, it is also installation. Thats for example
> the reason we added rinse to the packagel ist.
> 
> > Also wasting 350 mb of space on a cd is a (imho) stupid thing.
>  
> Wasting 4 GB on a DVD is also a stupid thing… I don't think the free
> space left on a device should be considered an argument at all. Only if
> it fits on a specific medium.
> 
> > I want my old grml-small and -full back. And as it seems I am not alone.
> 
> grml-full is the flavour name for the current release. grml-xl is atm
> the old package list.
> 
> If someone steps up regarding grml-xl sure. But the people involved in
> the release don't have the manpower to do it. And JFTR it does not only
> involve taking care of the package list but also checking the dailies,
> checking for dependency problems, testing RCs etc.
> 
> Long story short, the persons involved in the release process don't have
> the manpower or interest in grml-xl. If you want to see changes please
> start contributing&testing what works and actually work on making
> grml-xl releases a reality.
> 
> Ulrich
> 
> P.S: For a more personal view on the release process have a look at
> the blog entry of ch http://zeha.at/blog/2011/12/grml-pissed-off.html
> _______________________________________________
> Grml-devel mailing list
> Grml-devel at ml.grml.org
> http://ml.grml.org/mailman/listinfo/grml-devel