Re: Unsubscribing in order to killfile one individual. Was: Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages
On Monday 10 October 2016 19:04:22 Joe wrote: > On Mon, 10 Oct 2016 12:20:22 +0100 > > Lisi Reiszwrote: > > I accepted that analogy too easily. In this case, the wheel isn't > > squeaking. He dislikes the colour and design of the wheel. > > Or perhaps it has been squeaking for so long that nobody hears it any > more. Aptitude does a great job of routine upgrades, but if I've left > an unstable for a month or more without upgrading, I wouldn't consider > using it, it doesn't deal gracefully with hundreds of upgrades. I accept that. But I would also suggest that jacks of all trades are usually masters of none, and perhaps Aptitude is the wrong tool for you for that particular job. Libre Office does word processing MUCH better than Kwrite. Does this mean that Kwrite is a squeaky tool because it is bad at WP, or does it mean that I oughtn't to try to use it for that purpose? (LO, conversely,is bad at script editing, for which I love Kwrite.) Horses for courses. If Aptitude is not the ideal tool for everything, that doesn't make it a squeaky wheel. It just means that it shouldn't be used for everything. Lisi
Re: Unsubscribing in order to killfile one individual. Was: Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages
On Mon, 10 Oct 2016 12:20:22 +0100 Lisi Reiszwrote: > > I accepted that analogy too easily. In this case, the wheel isn't > squeaking. He dislikes the colour and design of the wheel. > Or perhaps it has been squeaking for so long that nobody hears it any more. Aptitude does a great job of routine upgrades, but if I've left an unstable for a month or more without upgrading, I wouldn't consider using it, it doesn't deal gracefully with hundreds of upgrades. -- Joe
Re: Unsubscribing in order to killfile one individual. Was: Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages
On Monday 10 October 2016 09:07:14 Joe wrote: > On Sun, 9 Oct 2016 21:11:07 -0400 (EDT) > > Bob Bernsteinwrote: > > On Mon, 10 Oct 2016, Lisi Reisz wrote: > > > Why not just killfile me and go on reading everyone else? > > > > Umm...cuz he doesn't know how to do that? Perhaps? > > > > One thing's fer sure, he's giving the time-honored tradition of > > killfiles a bad name! > > He's right though, isn't he? The wheel which squeaks, gets the oil. > Without complaints, things improve slowly, if at all. > > A formal complaint about a piece of software is the bug report, but > much of the time, things go wrong and there is insufficient data or > reproducibility to waste developers' time with an incomplete report. > Just about the only thing to do then is to moan about it publicly. > > If it's finger trouble, you find that out very quickly. If nobody > replies, you have something peculiar to your own system, or at least, > not widespread. Live with it. If there's a chorus of 'yes, I've got > that too, but I didn't like to moan', then enough collective data may > surface to make a bug report practical, or at least to come to the > notice of one of the developers, who may be able to shed further light. > > The alternatives of putting up with a problem in silence, or going > [back] to Windows, are not optimal. > > As for fixing the problem yourself, you are either: > a) a systems programmer, but you probably knew that already, or > b) a user, who could learn enough to contribute usefully in a year or > two, if you didn't have a living to earn. > > Fixing a bug so it doesn't happen again, and fixing a bug in a way that > doesn't break *anything* else, are two very different things. I have > enough trouble going back to my own (non-system) programming of a year > or more ago, and finding out how it works well enough to change > something without breaking it. It doesn't matter how many comments I > left, I have to get back into the same mindset as when I wrote it, > and I haven't worked out how to achieve that with comments. Details are > easy to see, it's the overall architecture that needs to be understood > fully. I accepted that analogy too easily. In this case, the wheel isn't squeaking. He dislikes the colour and design of the wheel. Lisi
Re: Unsubscribing in order to killfile one individual. Was: Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages
On Monday 10 October 2016 09:07:14 Joe wrote: > On Sun, 9 Oct 2016 21:11:07 -0400 (EDT) > > Bob Bernsteinwrote: > > On Mon, 10 Oct 2016, Lisi Reisz wrote: > > > Why not just killfile me and go on reading everyone else? > > > > Umm...cuz he doesn't know how to do that? Perhaps? > > > > One thing's fer sure, he's giving the time-honored tradition of > > killfiles a bad name! > > He's right though, isn't he? The wheel which squeaks, gets the oil. > Without complaints, things improve slowly, if at all. > > A formal complaint about a piece of software is the bug report, but > much of the time, things go wrong and there is insufficient data or > reproducibility to waste developers' time with an incomplete report. > Just about the only thing to do then is to moan about it publicly. > > If it's finger trouble, you find that out very quickly. If nobody > replies, you have something peculiar to your own system, or at least, > not widespread. Live with it. If there's a chorus of 'yes, I've got > that too, but I didn't like to moan', then enough collective data may > surface to make a bug report practical, or at least to come to the > notice of one of the developers, who may be able to shed further light. > > The alternatives of putting up with a problem in silence, or going > [back] to Windows, are not optimal. > > As for fixing the problem yourself, you are either: > a) a systems programmer, but you probably knew that already, or > b) a user, who could learn enough to contribute usefully in a year or > two, if you didn't have a living to earn. > > Fixing a bug so it doesn't happen again, and fixing a bug in a way that > doesn't break *anything* else, are two very different things. I have > enough trouble going back to my own (non-system) programming of a year > or more ago, and finding out how it works well enough to change > something without breaking it. It doesn't matter how many comments I > left, I have to get back into the same mindset as when I wrote it, > and I haven't worked out how to achieve that with comments. Details are > easy to see, it's the overall architecture that needs to be understood > fully. I quite agree with the idea that squeaks are needed. But there is a limit to how OFTEN it is useful to say it in the one thread. Lisi
Re: Unsubscribing in order to killfile one individual. Was: Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages
On Sun, 9 Oct 2016 21:11:07 -0400 (EDT) Bob Bernsteinwrote: > On Mon, 10 Oct 2016, Lisi Reisz wrote: > > > Why not just killfile me and go on reading everyone else? > > Umm...cuz he doesn't know how to do that? Perhaps? > > One thing's fer sure, he's giving the time-honored tradition of > killfiles a bad name! > He's right though, isn't he? The wheel which squeaks, gets the oil. Without complaints, things improve slowly, if at all. A formal complaint about a piece of software is the bug report, but much of the time, things go wrong and there is insufficient data or reproducibility to waste developers' time with an incomplete report. Just about the only thing to do then is to moan about it publicly. If it's finger trouble, you find that out very quickly. If nobody replies, you have something peculiar to your own system, or at least, not widespread. Live with it. If there's a chorus of 'yes, I've got that too, but I didn't like to moan', then enough collective data may surface to make a bug report practical, or at least to come to the notice of one of the developers, who may be able to shed further light. The alternatives of putting up with a problem in silence, or going [back] to Windows, are not optimal. As for fixing the problem yourself, you are either: a) a systems programmer, but you probably knew that already, or b) a user, who could learn enough to contribute usefully in a year or two, if you didn't have a living to earn. Fixing a bug so it doesn't happen again, and fixing a bug in a way that doesn't break *anything* else, are two very different things. I have enough trouble going back to my own (non-system) programming of a year or more ago, and finding out how it works well enough to change something without breaking it. It doesn't matter how many comments I left, I have to get back into the same mindset as when I wrote it, and I haven't worked out how to achieve that with comments. Details are easy to see, it's the overall architecture that needs to be understood fully. -- Joe
Re: Unsubscribing in order to killfile one individual. Was: Re: WARNING! New Perl/Perl-base upgrade removes 141 Sid/Unstable packages
On Mon, 10 Oct 2016, Lisi Reisz wrote: Why not just killfile me and go on reading everyone else? Umm...cuz he doesn't know how to do that? Perhaps? One thing's fer sure, he's giving the time-honored tradition of killfiles a bad name! -- IMPORTANT: This email is intended for the use of the individual addressee(s) named above and may contain information that is confidential, privileged or unsuitable for overly sensitive persons with low self-esteem, no sense of humour or irrational metaphysical beliefs.