[Grml-devel] About the new grml direction

[Christoph Biedl]

Ulrich Dangel wrote ...

> 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.

Lack of manpower is a problem.

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

So why not dropping -medium, and also the 650 Mbyte limit for -full? I
doubt many people still boot a Desktop system via CD, so I wouldn't
bother about a -full image of 1 Gbyte. Perhaps other people would, I
don't know.

> 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.

That's what you do user survey for. And you actually did.

So for me, there are two use cases:

1. Quite often: Use -small as a fits-everywhere system for rescue,
   recovery and repair on the root file system..
2. Every now and then: Use -full to have a browser without touching
   the actual installation and/or without leaving traces behind.

But I always wondered who needs -medium and if asked, abandoning it
would have been my first suggestion. But now, giving the impression
you've dropped everything _but_ -medium is sending the message I'm not
the target audience. Not a message I like.

> And i think with this release it became clear and obvious.

For me, it's mostly: "We try to make one that fits all" (*)

> 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.

Please don't tell you want to punish the satisfied Grml users just
because they were happy with the way Grml was.

> 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.

Well, I want to use the ISO image on /boot (old-style, no-thrills
/dev/sda1) all by itself, without having to rely on anything else on
that disk. So I installed a -small image on each of my boxes and even
on some external disks. Using USB sticks still may afford surprises -
no BIOS support, BIOS support flaky and failing for that particular
stick, BIOS providing just USB 1.x support, and mostly: Where the
*beep* did I put the stick _this_ time?

Slurping the image into memory ("toram") is an important thing, too:
If I want to fiddle with the partitioning, hence no partition my be
mounted. Or just to make things fast.

But now:

* Not everywhere the disk has enough space in /boot for the 2011.12
  image, and re-partitioning is a tiresome process even if using LVM
  (what I do), I don't want to do that again.
* The copy operation of toram *is* fast on shiny new hardware. It's
  not so funny on older one. That time tripled now - no thanks.

Friends of mine - who were unanimously complaing about the loss of
-small - also mentioned the situation of finding themselves alone in
the wild with nothing but a broken machine where Grml would be a tool
to fix it, and an internet connection. Why download 300+ Mbyte, and
wait for it, if 110 did the job?

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

Bring back good ol' S^H-small. It's the main thing why I use, like and
promote Grml. Doing a private -small release for myself might be a way
to go but that's not helping, neither the Grml project nor other
people who miss -small, too.

So, what were the -small hacks? Open tickets, or provide a pointer,
and we'll see.

> 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.

Rest assured Grml has a very pleased user base, perhaps a bit too
quiet, and as always more taking than giving. A "Keep Grml just the
way it is, it's almost perfect" might be boring but it's actually a
compliment about the things you've achieved in the past seven-ish
years.

My experience is a typical (Linux) sysadmin naturally just uses Grml
without talking much about it. Especially when using Debian, Grml is
the first choice as it's the same distribution.

So, please don't worry too much. Dare to ask for help if you need it.
And bring back -small.

    Christoph

(*) But see RFC 1926, (10)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ml.grml.org/pipermail/grml-devel/attachments/20111227/d843f076/attachment-0001.pgp>