removal of "buffer" command? alternatives?
Hi-
Up until this release, the 'buffer' command was included.
I use this all the time. Things like:
nc -l 12345 | buffer -z256k -p75 -m10m -o /dev/sda
Gone? :(
Is there an alternative?
-Tom
Hmmm... 'atop' also? Not as bad as 'buffer', but, I'm having withdrawal.
Is there a list of what was removed?
I'm unconvinced that filling 50% of iso images with unused stuff (64 unused on 32, 32 unused on 64...) is an ideal trade-off. I'm just sayin...
For now I'm back on 11.5...
-Tom
On Tue, Dec 27, 2011 at 03:07:53PM -0500, Tom {Tomcat} Oehser wrote:
Hi-
Up until this release, the 'buffer' command was included.
I use this all the time. Things like:
nc -l 12345 | buffer -z256k -p75 -m10m -o /dev/sda
Gone? :(
Is there an alternative?
-Tom
-- "Let us do our duty in our shop or our kitchen, the market, the street, the office, the school, the home, just as faithfully as if we stood in the front rank of some great battle, and we knew that victory for mankind depended upon our bravery, strength, and skill. When we do that the humblest of us will be serving in that great army which achieves the welfare of the world." --Theodore Parker The little girl expects no declaration of tenderness from her doll. She loves it -- and that's all. It is thus that we should love. -- DeGourmont _______________________________________________ Grml mailing list - Grml@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog: http://blog.grml.org/
* Tom {Tomcat} Oehser wrote [28.12.11 00:45]: Hi,
Hmmm... 'atop' also? Not as bad as 'buffer', but, I'm having withdrawal.
Yes, have a look at htop instead.
Is there a list of what was removed?
Yes, you can either create your own list by comapring the dpkg selection files or use http://daily.grml.org:8080/job/grml64_Release/25/artifact/changelog.txt which has a removed section
I'm unconvinced that filling 50% of iso images with unused stuff (64 unused on 32, 32 unused on 64...) is an ideal trade-off. I'm just sayin...
Hm? The default images are 64bit or 32bit only.
Ulrich
Yes, have a look at htop instead.
atop/htop I don't care so much about, but, buffer is more of an issue.
Ouch! Even lzop is gone! This is 2/3 or a command I use very often!
buffer -i <device> -z256k -p75 -m10m | lzop | buffer | nc <hostname>
And while I can always fake buffer with 'dd' and bad performance, if I have a backup in .lzop format, I'm just screwed now!
I'm unconvinced that filling 50% of iso images with unused stuff (64 unused on 32, 32 unused on 64...) is an ideal trade-off. I'm just sayin...
Hm? The default images are 64bit or 32bit only.
I guess I was figuring that the cute point of going from 700mb to 350mb was to fit both images on the 96.
Frankly, I boot GRML from 4GB USB sticks, which are costing $8, I don't even put an optical drive in machines anymore. I do not see the point of reducing functionality. For what? Bandwidth is going up, media sizes are going up, prices are going down... I think it is a good idea to keep the media size at CDROM size or less, but, 350? I do - not - see - the - point! I mean, what media are smaller than 700 and larger than 300? How many people are going to prefer the quicker download? First ubuntu, now grml? <rant='off'/>
When I read the description, I thought, this sounds fine, after all, I don't need my sysadmin tool to have 50 zillion window managers... but I didn't expect to find text-mode command-line tools I use like buffer and atop gone! Now I'm afraid to look to see what else is missing that matters...
Now, I love smallifying more than _anyone_ - tomsrtbt was my doing, back in the day - and I could certainly figure out how to customize and add stuff in.
But, the reality is that I switched from my own tomsrtbt to knoppix and then to grml because they "just worked" - grml has the lvm2 and the swraid and the command line tools I need - it had become the 'answer' to my bootable system needs. For me, going from 700=>350 has no "upside", with a fast connection and a 4GB USB stick.
Glancing through the "removed" list, I don't _know_ i'll need arj or bin86 or cpuburn or dsniff or expect or fatattr or gdb or hexedit or info or etcetera during a recovery situation - but I know I'd rather have them than not have them!
Is the "full" version just *gone*? I really *liked* the mix of software there!
-ack! -Tom
* Tom {Tomcat} Oehser wrote [28.12.11 05:32]:
Ouch! Even lzop is gone! This is 2/3 or a command I use very often!
buffer -i <device> -z256k -p75 -m10m | lzop | buffer | nc <hostname>
And while I can always fake buffer with 'dd' and bad performance, if I have a backup in .lzop format, I'm just screwed now!
I added lzop to the package list. The next daily images will contain lzop - http://git.io/H2XqNQ
Hm? The default images are 64bit or 32bit only.
I guess I was figuring that the cute point of going from 700mb to 350mb was to fit both images on the 96.
Coincidence. We didn't even plan to release grml96 but a user pointed it out that it would be neat to have both of them on a ISO image with the current size.
Frankly, I boot GRML from 4GB USB sticks, which are costing $8, I don't even put an optical drive in machines anymore. I do not see the point of reducing functionality. For what? Bandwidth is going up, media sizes are going up, prices are going down... I think it is a good idea to keep the media size at CDROM size or less, but, 350? I do - not - see - the - point! I mean, what media are smaller than 700 and larger than 300? How many people are going to prefer the quicker download? First ubuntu, now grml? <rant='off'/>
First of all it is about manpower. We do not have enough man power to release all the flavours and test everything. And it is not only about the size but download speed is also a big factor. And it also takes more time to transfer an image into ram (grml2ram) with the bigger version. And loading the old 700mb image into RAM is not possible on systems with only 512MB ram.
OTOH it is also possible to place grml for example on /boot and use it as a rescue medium directly from the boot partition. Most /boot partitions are not bigger than 500MB.
But, the reality is that I switched from my own tomsrtbt to knoppix and then to grml because they "just worked" - grml has the lvm2 and the swraid and the command line tools I need - it had become the 'answer' to my bootable system needs. For me, going from 700=>350 has no "upside", with a fast connection and a 4GB USB stick.
JFTR lvm/swraid etc. are still available. We just removed software like
Glancing through the "removed" list, I don't _know_ i'll need arj or bin86 or cpuburn or dsniff or expect or fatattr or gdb or hexedit or info or etcetera during a recovery situation - but I know I'd rather have them than not have them!
We readded hexedit. But tbh i don't think dsniff or expect are really useful on a live cd.
Is the "full" version just *gone*? I really *liked* the mix of software there!
The package list is still in the git repository (grml-live) under the name grml-full. We need volunteers doing the work. The current team is not able to produce it. Brad Cable already offered his help re. GRML_XL.
Btw. if you are interested in this topic we are already discussing it on grml-devel, please have a look at the grml devel mailinglist http://ml.grml.org/mailman/listinfo/grml-devel i already answered some details in http://ml.grml.org/pipermail/grml-devel/2011-December/000215.html and the other messages. It would be great if we can discuss the issue on the grml-devel mailingst.
cheers, Ulrich
P.S: For a short introduction about remastering Grml have a look at http://blog.grml.org/archives/364-Remastering-Grml-2011.12-will-be-as-easy-a...
Hi,
On Wed, Dec 28, 2011 at 02:28:13AM +0100, Ulrich Dangel wrote:
- Tom {Tomcat} Oehser wrote [28.12.11 00:45]:
Hi,
Hmmm... 'atop' also? Not as bad as 'buffer', but, I'm having withdrawal.
Yes, have a look at htop instead.
Is there a list of what was removed?
Yes, you can either create your own list by comapring the dpkg selection files or use http://daily.grml.org:8080/job/grml64_Release/25/artifact/changelog.txt which has a removed section
I am a bit sad glancing on that list. Some of the tools removed are big (ok, so one can accept that and it can be justified), but most of them are small so from the size point of view it does not help if you remove.
I name just a few: afio aircrack-ng awesome (i do not use this a friend does) build-essential (so from now on building inside grml will be not that easy) gcc, g++ also gone... comgt (180k) dns2tcp (201k) (I am using this if I stay at a hotel with insane internet rates) emacs23 (this is a beast I know, more than one friend use this) fakeroot firmware-qlogic (this means that it will not boot on server containing FC card?) irssi ipmitool ldapvi libnet-*-perl mutt postfix (I was using this for educating mailing basics also good for testing) pppoe (no one with adsl anymore?) radvd runit (520k) rxvt-unicode (this was part or the release from the begining) tcptraceroute virtualbox tp_smapi zsh-lovers is your package afaik
If a tool is used when you are online it makes sense to remove it (nsd, bind9) and one can reinstall easily. If you remove pppoe how can one connect facing an adsl connection? If an package mostly used offline is removed a functionality is lost.
I make my /boot 1Gb to be able to put a grml there for recovery purposes.
I used to make my own (remaster) grml flavour and a bit of this or that. But now that most of the tools gone maybe I will just stick to the old one.
I used to recommend grml to friends who are not that experienced to make their own grml (and to tell the truth most of us are just lazy or lack the time).
What kind of testing is needed to get (most/some of) the tools back on the cd? I used to be around on IRC, but when some folk switched from english I was unable to follow the conversation so I dropped out.
I want grml to be *the* rescue/sysadmin cd again not just one of the bootable linux cds out there. Thanks.
Regards, cstamas
* Csillag Tamas cstamas@digitus.itk.ppke.hu [111228 11:08]:
[..] pppoe (no one with adsl anymore?) [..]
If a tool is used when you are online it makes sense to remove it (nsd, bind9) and one can reinstall easily. If you remove pppoe how can one connect facing an adsl connection? If an package mostly used offline is removed a functionality is lost.
pppoe is the old rp-pppoe code.
ppp (which is included) can do normal PPP and PPPoE.
Please check your facts before bringing up red herrings.
-ch
On Wed, Dec 28, 2011 at 12:27:17PM +0100, Christian Hofstaedtler wrote:
- Csillag Tamas cstamas@digitus.itk.ppke.hu [111228 11:08]:
[..] pppoe (no one with adsl anymore?) [..]
If a tool is used when you are online it makes sense to remove it (nsd, bind9) and one can reinstall easily. If you remove pppoe how can one connect facing an adsl connection? If an package mostly used offline is removed a functionality is lost.
pppoe is the old rp-pppoe code.
ppp (which is included) can do normal PPP and PPPoE.
Please check your facts before bringing up red herrings.
Sorry If I made mistakes. It was unintentional.
Regards, cstamas
Csillag Tamas wrote:
On Wed, Dec 28, 2011 at 02:28:13AM +0100, Ulrich Dangel wrote:
[...]
http://daily.grml.org:8080/job/grml64_Release/25/artifact/changelog.txt which has a removed section
I am a bit sad glancing on that list. Some of the tools removed are big (ok, so one can accept that and it can be justified), but most of them are small so from the size point of view it does not help if you remove.
Here is my take on the subject: As other members of the team have pointed out, these rather severe have been done because there we don't have the manpower to keep the large set of packages rolling properly. We do realise, that not everything may be perfect. But it is equally important, that everyone understands, that the few people who do the major work on rolling out releases (and I am not one of them by a long shot) on a fairly regular schedule only have 24 hours in a day, just like everyone else. The workload needed to be contained at a doable level.
That aside, I don't see the changes as being damaging, but rather as a chance. I agree that there are some packages that are missing. But it's only *now* that we get to know what these packages were. It is a well deserved cleanup of our list of packages, because we now get to see which packages deserve attention and which do not.
afio
Agreed. I used to have my backups handled with afio scripts. But there seems to be issues with afio copyright (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509287 for details) and there is no package in debian testing right now.
So that's kind of a little hairy. (But I'd like to see this packages included again, too, if that's possible at all.)
aircrack-ng
No official debian package. We can't maintain it. http://packages.qa.debian.org/a/aircrack-ng.html
Otherwise it might well be in.
awesome (i do not use this a friend does)
Yes. WindowManagers. Again. We won't be maintaining a proper configuration for awesome and we'd also like this particular part of the distribution to be more uniform than before. If you must have it, grml-live is your friend.
build-essential (so from now on building inside grml will be not that easy) gcc, g++ also gone...
I'm finding this a little sad too. But build-essential is probably not enough to build most stuff anyway. So you'll need to install stuff already and you can just install build-essential along the way with that.
comgt (180k)
Can probably included. Our very own jimmy is the maintainer of the debian package, even. ;)
dns2tcp (201k) (I am using this if I stay at a hotel with insane internet rates)
A bit specialised, but a debian package is available and it would be reasonable added functionality at the cost of a pretty small package. So, I'd be for including this.
emacs23 (this is a beast I know, more than one friend use this)
Yeah. No. Don't get me wrong, I'm an emacs user *myself*. But if you don't have your setup along, it's useless. Well, not useless, but way less useful.
I'd include `mg' which is a tiny emacs-like editor.
If you want emacs23 (or even 24) - again - grml-live is your friend.
fakeroot
What's the use-case here? I mean, including it would be possible, but I don't see what for, off hand.
firmware-qlogic (this means that it will not boot on server containing FC card?)
Hm. this one's non-free. I don't know what else is blocking that. Someone else would have to comment.
irssi
I'd like at least one IRC client on the ISO, too. It's useful for crying for help when something goes haywire. Irssi or epic are reasonable suspects, I guess. Maybe even weechat (although I think the default behaviour is insane).
ipmitool
Um, no idea... I guess this one wouldn't hurt.
ldapvi
Again, no idea.
libnet-*-perl
As a Perl hacker, I'd agree. But I don't know how much space this would take. Maintaining such a proper list wouldn't be trivial either, I'd imagine.
mutt
I don't know. Without setup, you can't do much with mutt. I think this is a clear case for a private package list and grml-live again.
postfix (I was using this for educating mailing basics also good for testing)
grml-live, I guess.
pppoe (no one with adsl anymore?)
Hm. Yeah. Maybe someone can comment on that one.
radvd
No opinion.
runit (520k)
What for? We don't use it.
rxvt-unicode (this was part or the release from the begining)
There's xterm. I wouldn't mind if this would be included. But I guess this is yet another candidate for grml-live.
tcptraceroute
I wouldn't mind
virtualbox
grml-live. Really.
tp_smapi
There were issues with dmks, IIRC.
zsh-lovers is your package afaik
Well, I don't really see the use on a simple disk. Never looked at it even once on there.
[...]
What kind of testing is needed to get (most/some of) the tools back on the cd? I used to be around on IRC, but when some folk switched from english I was unable to follow the conversation so I dropped out.
Well, it would be useful to do some research before requesting packages: Is there a debian package, is it free/non-free, are there any severe problems with it? Etc. etc.
And finally: I am not a fan of the grml96 ISOs and I was only realising that they existed after the release. Here is why I don't like them: The cleaned up package list leaves us with huge amounts of free space on a standard blank CD. It would be trivial to say "What, you'd like afio back? Well. No problem. Readded it. Get tomorrows daily image."
Now there is a new artificial limit: If we add a lot of new packages, then grml96 may overflow. And if that limits what we'd include in our images, that would be *quite* unfortunate to say the least.
I realise, that grml96 may contain a completely different set of packages then the single-arch package. But I wouldn't want to diverge too much, because it would lead to confusion and pain. And it's trivial to create a bootable medium with both architectures using, say, grml2usb.
Regards, Frank
* Frank Terbeck [Wed Dec 28, 2011 at 01:43:22PM +0100]:
Csillag Tamas wrote:
irssi
I'd like at least one IRC client on the ISO, too. It's useful for crying for help when something goes haywire. Irssi or epic are reasonable suspects, I guess. Maybe even weechat (although I think the default behaviour is insane).
Hm, good point. But the ones needing help need network access anyway, so they can just install their favourite IRC client anyway, no? (I'm aware that we did provide out-of-the-box config for irssi which just joined our channel, but I didn't see that many people using that actually.)
And finally: I am not a fan of the grml96 ISOs and I was only realising that they existed after the release. Here is why I don't like them: The cleaned up package list leaves us with huge amounts of free space on a standard blank CD. It would be trivial to say "What, you'd like afio back? Well. No problem. Readded it. Get tomorrows daily image."
Now there is a new artificial limit: If we add a lot of new packages, then grml96 may overflow. And if that limits what we'd include in our images, that would be *quite* unfortunate to say the least.
I realise, that grml96 may contain a completely different set of packages then the single-arch package. But I wouldn't want to diverge too much, because it would lead to confusion and pain. And it's trivial to create a bootable medium with both architectures using, say, grml2usb.
grml96 is the result of one single grml2iso command line, so it won't receive a different package list than grml32 and grml64 but instead will just continue being the result of the two ISOs getting combined, from my POV.
And IIRC Christian already mentioned that he doesn't consider the "artificial limit" an real issue for grml96, and I don't really neither.
I don't consider CDs that relevant anymore nowadays. Either the hardware can boot of USB/PXE or the hardware is that old that an old version/release should work as well. So from my POV it's more important to provide a decent grml32/grml64 version which has sane size limits. grml96 could also increase to over 700MB in size, since <=512MB won't be possible anyway and the next common USB pen size limit is 1GB. If booting from CD is *that* important and relevant you shouldn't care about the MBs that you're "losing" with burning the ~350MB grml32/grml64 ISO to CD.
regards, -mika-
Michael Prokop wrote:
- Frank Terbeck [Wed Dec 28, 2011 at 01:43:22PM +0100]:
I'd like at least one IRC client on the ISO, too. It's useful for crying for help when something goes haywire. Irssi or epic are reasonable suspects, I guess. Maybe even weechat (although I think the default behaviour is insane).
Hm, good point. But the ones needing help need network access anyway, so they can just install their favourite IRC client anyway, no? (I'm aware that we did provide out-of-the-box config for irssi which just joined our channel, but I didn't see that many people using that actually.)
True. But still. ;)
The client I'm installing on my machines (I'm connected 24/7 on one machine that has `irssi') is usually `epic4', because it does *not* require any configuration.
% irc nickname irc.freenode.net
...and I'm on freenode. That's enough for quick chats, IMHO. `ircii' is even simpler and only requires minimal dependencies, but epic is a little more convenient to use out-of-the-box, I think (and we probably ship its dependencies already). Both are alternatives for the `irc' command used above.
If you're firmly against it, I don't care too much.
[...]
grml96 is the result of one single grml2iso command line, so it won't receive a different package list than grml32 and grml64 but instead will just continue being the result of the two ISOs getting combined, from my POV.
That's good. Although, I'd probably burden people with calling grml2iso themselves. But you guys are better people than me. ;-)
And IIRC Christian already mentioned that he doesn't consider the "artificial limit" an real issue for grml96, and I don't really neither.
So the policy is rather: Here's an image with grml32+64 for your convenience, but be advised that it may not fit on a blank CD, but probably on your USB pen-drive.
[...]
If booting from CD is *that* important and relevant you shouldn't care about the MBs that you're "losing" with burning the ~350MB grml32/grml64 ISO to CD.
I couldn't agree more. The quicker `toram' beats the living shit out of a half-full CD.
Regards, Frank
* Frank Terbeck [Wed Dec 28, 2011 at 03:40:29PM +0100]:
Michael Prokop wrote:
[irc client]
Hm, good point. But the ones needing help need network access anyway, so they can just install their favourite IRC client anyway, no? (I'm aware that we did provide out-of-the-box config for irssi which just joined our channel, but I didn't see that many people using that actually.)
True. But still. ;)
The client I'm installing on my machines (I'm connected 24/7 on one machine that has `irssi') is usually `epic4', because it does *not* require any configuration.
% irc nickname irc.freenode.net
...and I'm on freenode. That's enough for quick chats, IMHO. `ircii' is even simpler and only requires minimal dependencies, but epic is a little more convenient to use out-of-the-box, I think (and we probably ship its dependencies already). Both are alternatives for the `irc' command used above.
Ok thanks! Added them to the list of software packages open for discussion.
[...]
grml96 is the result of one single grml2iso command line, so it won't receive a different package list than grml32 and grml64 but instead will just continue being the result of the two ISOs getting combined, from my POV.
That's good. Although, I'd probably burden people with calling grml2iso themselves. But you guys are better people than me. ;-)
Let's see what kind of feedback we get regarding grml96.
And IIRC Christian already mentioned that he doesn't consider the "artificial limit" an real issue for grml96, and I don't really neither.
So the policy is rather: Here's an image with grml32+64 for your convenience, but be advised that it may not fit on a blank CD, but probably on your USB pen-drive.
Jepp :)
If booting from CD is *that* important and relevant you shouldn't care about the MBs that you're "losing" with burning the ~350MB grml32/grml64 ISO to CD.
I couldn't agree more. The quicker `toram' beats the living shit out of a half-full CD.
:))
regards, -mika-
* Frank Terbeck ft@grml.org [111228 13:43]:
And finally: I am not a fan of the grml96 ISOs and I was only realising that they existed after the release. Here is why I don't like them: The cleaned up package list leaves us with huge amounts of free space on a standard blank CD. It would be trivial to say "What, you'd like afio back? Well. No problem. Readded it. Get tomorrows daily image."
Now there is a new artificial limit: If we add a lot of new packages, then grml96 may overflow. And if that limits what we'd include in our images, that would be *quite* unfortunate to say the least.
I can see us releasing a single ISO, with a 32bit userland and kernels for 64bit and 32bit for maybe the next or next-next release. Ulrich is pushing hard for this, and (while I don't necessarily like it) I think that's the correct way forward for the time being (read: as long as i386 still lives).
I realise, that grml96 may contain a completely different set of packages then the single-arch package. But I wouldn't want to diverge too much, because it would lead to confusion and pain. And it's trivial to create a bootable medium with both architectures using, say, grml2usb.
(As others have pointed out, grml96 is basically the result of a grml2usb/grml2iso call.)
-ch
* Csillag Tamas [Wed Dec 28, 2011 at 11:08:29AM +0100]:
I am a bit sad glancing on that list. Some of the tools removed are big (ok, so one can accept that and it can be justified), but most of them are small so from the size point of view it does not help if you remove.
I name just a few: afio
Will be further discussed [1]
aircrack-ng
Not available from Debian anymore/yet
awesome (i do not use this a friend does)
Was discussed but wasn't considered to be essential enough to be included.
build-essential (so from now on building inside grml will be not that easy) gcc, g++ also gone...
It's not considered as part of our install & rescue" mission to compile software on the live system. If you want/need a full-featured development environment we recommend remastering and ship everything *you* need.
comgt (180k)
Thanks, re-added already: http://git.io/rtTeQg
dns2tcp (201k) (I am using this if I stay at a hotel with insane internet rates)
Will be further discussed [1]
emacs23 (this is a beast I know, more than one friend use this)
Sorry, I like and use emacs on my own, but emacs23 is just too large for inclusion and doesn't match our "install & rescue" mission neither.
fakeroot
Will be further discussed [1]
firmware-qlogic (this means that it will not boot on server containing FC card?)
Will be further discussed [1]
irssi
If you've network access you can just install it :)
ipmitool
Will be further discussed [1]
ldapvi
Will be further discussed [1]
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?
mutt postfix (I was using this for educating mailing basics also good for testing)
Both shouldn't be relevant for a live system (and both don't match the install and rescue mission), and if you've network access you can once again just install it :)
pppoe (no one with adsl anymore?)
See Christian's mail
radvd
Will be further discussed [1]
runit (520k)
What's the benefit for the live system?
rxvt-unicode (this was part or the release from the begining)
xterm is there and should be enough for install and rescue mission, IMO
tcptraceroute
Will be further discussed [1]
virtualbox tp_smapi
External kernel modules available via DKMS can't be shipped as standalone binary Debian packages yet (due to limitations in DKMS). Evgeni Golov is working on something to resolve that, but until this is ready-to-go I'm afraid we won't provide external kernel packages.
zsh-lovers is your package afaik
It wasn't considered relevant enough for the install and rescue mission. Not sure what our people think about it?
If a tool is used when you are online it makes sense to remove it (nsd, bind9) and one can reinstall easily. If you remove pppoe how can one connect facing an adsl connection? If an package mostly used offline is removed a functionality is lost.
See Christian's mail (short version: ppp still supported, pppoe is old and deprecated).
I make my /boot 1Gb to be able to put a grml there for recovery purposes.
Same for me :)
I used to make my own (remaster) grml flavour and a bit of this or that. But now that most of the tools gone maybe I will just stick to the old one.
Remastering became easier than ever with this release:
http://blog.grml.org/archives/364-Remastering-Grml-2011.12-will-be-as-easy-a...
And there's no reason to not remaster it. We can't provide one Grml version that makes everyone happy. (And the old model just doesn't work for us any longer if the manpower stays the same, see below.)
I used to recommend grml to friends who are not that experienced to make their own grml (and to tell the truth most of us are just lazy or lack the time).
Well, that's exactly our problem: we also lack time and we couldn't keep the project up and running any longer if we wouldn't have chosen the "reset button" for this release. With 3 flavours for 2 architectures we had way too many ISOs to support with the available manpower.
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,...
* taking care of bugs (see http://bts.grml.org/grml/) and user support ("why doesn't foo work?")
We highly appreciate and welcome any contributors helping us out.
Reminder: we're an open source project. Everyone can contribute and improve areas where work needs to be done. But we just can't do all the work for you if it's "just take but don't give back".
I used to be around on IRC, but when some folk switched from english I was unable to follow the conversation so I dropped out.
Sorry for that. The channel language is english-only nowadays, so please feel free to join the IRC channel again.
I want grml to be *the* rescue/sysadmin cd again not just one of the bootable linux cds out there. Thanks.
Thanks for your feedback, we highly appreciate that.
[1] Thanks for the list. We will review and discuss your software selection in further detail, promised.
regards, -mika-
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
* Csillag Tamas [Wed Dec 28, 2011 at 03:24:49PM +0100]:
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]:
- 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.
Absolutely, and we take care of that already. But it's work that needs to be done, and the more packages we ship the more bugs we might (and usually) run into. And there *are* bugs which prevent us from building daily ISOs which then need special attention and workarounds/patches/.... That's where we need help as well.
regards, -mika-
participants (6)
-
Christian Hofstaedtler -
Csillag Tamas -
Frank Terbeck -
Michael Prokop -
Tom {Tomcat} Oehser -
Ulrich Dangel