f o On Sat, 20 Aug 2022, 8:28 am , <debian-user-digest-requ...@lists.debian.org> wrote:
> Content-Type: text/plain > > debian-user-digest Digest Volume 2022 : > Issue 675 > > Today's Topics: > Re: Raising volume past 100% [ David Griffith <d...@661.org> ] > Re: Why are some Debian bugs ignored [ piorunz <pior...@gmx.com> ] > Re: Raising volume past 100% [ Cindy Sue Causey > <butterflybytes@gm ] > Re: Why are some Debian bugs ignored [ Chuck Zmudzinski > <brchuckz@netscape ] > Re: Why are some Debian bugs ignored [ Chuck Zmudzinski > <brchuckz@netscape ] > Re: Why are some Debian bugs ignored [ Andy Smith <a...@strugglers.net> > ] > must i consider zfs or lvm for smr l [ Samuel Wales < > samolog...@gmail.com> ] > Re: Why are some Debian bugs ignored [ Chuck Zmudzinski > <brchuckz@netscape ] > Date: Fri, 19 Aug 2022 20:24:13 +0000 (UTC) > From: David Griffith <d...@661.org> > To: Bret Busby <b...@busby.net> > cc: debian-user@lists.debian.org > Subject: Re: Raising volume past 100% > Message-ID: <b6248c6c-4b86-a0e4-8b93-5a58af5a6...@661.org> > Content-Type: multipart/mixed; > BOUNDARY="1371591299-517002983-1660940421=:10482" > Content-ID: <3e2eb516-8f9-dcbe-1d69-2a68efca4...@661.org> > > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. > > --1371591299-517002983-1660940421=:10482 > Content-Type: text/plain; CHARSET=ISO-8859-15; format=flowed > Content-Transfer-Encoding: 8BIT > Content-ID: <5ea6d2d-133-b823-c9d1-badfcc32...@661.org> > > > On Fri, 19 Aug 2022, Bret Busby wrote: > > On 19/8/22 03:04, David Griffith wrote: > >> > >> On Fri, 19 Aug 2022, Bret Busby wrote: > >>> On 19/8/22 01:32, David Griffith wrote: > >>>> > >>>> My reply is at the bottom. Please put your reply there too. > >>>> On Thu, 18 Aug 2022, Bret Busby wrote: > >>>>> On 18/8/22 16:15, David Griffith wrote: > >>>>>> > >>>>>> There is the continuing problem of built-in speakers on laptops > being > >>>>>> too quiet when running Linux. I managed to fix this with something > in > >>>>>> /etc/asound.conf and an extra mate-volume-control applet added to > the > >>>>>> panel. With this extra volume control, I was able to turn the > audio > >>>>>> far past 100% and even past 153%. The laptop I'm working on needed > to > >>>>>> be wiped and the OS reinstalled. Unfortunately I neglected to save > or > >>>>>> write down what I did to implement this volume control tweak. > >>>>>> > >>>>>> Before I discovered this, I used /etc/asound.conf (or ~/.asoundrc) > to > >>>>>> add a "Pre-Amp" slider to Alsa. This raises up the low end such > that > >>>>>> the really quiet audio stuff is loud enough. I'm not sure if that > had > >>>>>> anything to do with the volume control tweak. > >>>>>> > >>>>>> Would someone please help me with figuring out what I could have > >>>>>> possibly done to make MATE's audio control applet to go as far past > >>>>>> 100% as I cared to raise it? > >>>>> > >>>>> Do you have access to the MATE Control Center, through the > applications > >>>>> menu? > >>>>> > >>>>> If so, in there, is the Hardware -> Sound settings configurator > >>>>> > >>>>> Also, in System -> Preferences -> Hardware -> Sound > >>>>> > >>>>> Whilst this is on a UbuntuMATE system, I expect that you should, if > you > >>>>> are using the MATE desktop environment, have access the same way, to > the > >>>>> same functionalities. > >>>> > >>>> I'm on a regular Debian system. What you pointed me to is the same > thing > >>>> that I get if I right-click on the volume control applet and select > >>>> "sound preferences". I'm not clear on what I'm supposed to see there > as > >>>> it has no visible options to raise the maximum volume. > >>> > >>> 1. As a person whom strictly bottom posts as a rule, and, as this was > >>> clearly shown in the message above, your comment at the top of the > >>> message, is not appreciated. > >> > >> Sorry. That tag has been part of my reply header for some time. I'll > >> reword it. > >> > >>> 2. See attachment. The slider goes past 100%, which, from your wording > in > >>> your request, is what I understand that you seek. > >> > >> What I seek is 1) the ability to hover the mouse pointer over the > volume > >> applet and raise the volume past 100% using the mouse wheel and 2) the > >> ability to click on the volume applet and use the slider that appears > to > >> raise the volume past 100%. I already know how to bring up a dialog to > do > >> this. I was able to do #1 before an untimely wipe and reinstall and am > >> having trouble figuring out just what I did. > > > > What is wrong with simply bringing up the Sound preferences window, and > > clicking on the position of the marker on the slider, and dragging it to > the > > position wanted? > > > > Your original query did not specify that you wanted instead, to be using > a > > mouseover and the mouse wheel, instead of the buttons on the mouse. > > I don't want to go through multiple clicks and the open/close of a dialog > box. Sometimes I get files/streams that are so quiet that even the max > provided by that method of 153% is not enough. I don't want a dialog > popping over what I'm doing. I was previously able to do exactly what I > wanted, so I know that it's possible. Also, I have come across repeated > requests on how to do what I'm trying to rediscover, so I'd like to get > the answer put out there for them. > > > -- > David Griffith > d...@661.org > > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > --1371591299-517002983-1660940421=:10482-- > Date: Fri, 19 Aug 2022 21:44:57 +0100 > From: piorunz <pior...@gmx.com> > To: debian-user@lists.debian.org > Subject: Re: Why are some Debian bugs ignored for a long time? > Message-ID: <1d7aa7b3-0791-11cf-2a12-f83a5398c...@gmx.com> > Content-Language: en-GB > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: quoted-printable > > On 19/08/2022 18:57, Chuck Zmudzinski wrote: > > > I have noticed that some Debian bugs are ignored for a long time, someti= > mes even when the person who submitted the bug offered a patch. The Debian= > developers/maintainers sometimes don't even reply and therefore never exp= > lain why the proposed patch cannot be applied. Why is that the case with D= > ebian developers/maintainers? > > Hi Chuck, > > Maybe because developers/maintainers are not paid by the hour, but mere > volunteers, don't you think? > > =2D- > With kindest regards, Piotr. > > =E2=A2=80=E2=A3=B4=E2=A0=BE=E2=A0=BB=E2=A2=B6=E2=A3=A6=E2=A0=80 > =E2=A3=BE=E2=A0=81=E2=A2=A0=E2=A0=92=E2=A0=80=E2=A3=BF=E2=A1=81 Debian - T= > he universal operating system > =E2=A2=BF=E2=A1=84=E2=A0=98=E2=A0=B7=E2=A0=9A=E2=A0=8B=E2=A0=80 https://ww > = > w.debian.org/ > =E2=A0=88=E2=A0=B3=E2=A3=84=E2=A0=80=E2=A0=80=E2=A0=80=E2=A0=80 > Date: Fri, 19 Aug 2022 17:00:39 -0400 > From: Cindy Sue Causey <butterflyby...@gmail.com> > To: Debian Users <debian-user@lists.debian.org> > Subject: Re: Raising volume past 100% > Message-ID: < > cao1p-kdrhss9vm7wautvtspl4ea97o+81uu2hsh5u1bwhjq...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On 8/19/22, David Griffith <d...@661.org> wrote: > > > > I don't want to go through multiple clicks and the open/close of a dialog > > box. Sometimes I get files/streams that are so quiet that even the max > > provided by that method of 153% is not enough. I don't want a dialog > > popping over what I'm doing. I was previously able to do exactly what I > > wanted, so I know that it's possible. Also, I have come across repeated > > requests on how to do what I'm trying to rediscover, so I'd like to get > > the answer put out there for them. > > > Hi.. This thread caught my eye because I'd been having trouble for a > couple weeks. Have you always had this trouble, or is this something > that just started happening in the last few weeks? > > Am asking because I started having a problem. I just assumed "Not > Gonna Take It Anymore" blew out the speakers on my newest secondhand > laptop. Might still be what happened, but it's that part about how low > it is that makes me wonder. > > Mine's so low, I have to lean completely against the laptop to hear > anything. Again, it's likely the hardware, but it's sure a funny > coincidence to see that very thing stated on here, too. > > pavucontrol is my weapon of choice to get anything resembling sound. > Didn't used to work for me. Had been using aumix for years then it > stopped working. Now pavucontrol(-qt) works mostly dependably, > although I have to log out and back in a couple times a week when it > doesn't make its connection(s) for currently unknown reasons. > > Cindy :) > -- > Talking Rock, Pickens County, Georgia, USA > * runs with birdseed * > Date: Fri, 19 Aug 2022 17:06:38 -0400 > From: Chuck Zmudzinski <brchu...@netscape.net> > To: debian-user@lists.debian.org > Subject: Re: Why are some Debian bugs ignored for a long time? > Message-ID: <cd457fbe-cfd4-4ee2-5655-9e46d6ece...@netscape.net> > Content-Language: en-US > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 7bit > > On 8/19/2022 4:44 PM, piorunz wrote: > > On 19/08/2022 18:57, Chuck Zmudzinski wrote: > > > > > I have noticed that some Debian bugs are ignored for a long time, > sometimes even when the person who submitted the bug offered a patch. The > Debian developers/maintainers sometimes don't even reply and therefore > never explain why the proposed patch cannot be applied. Why is that the > case with Debian developers/maintainers? > > > > Hi Chuck, > > > > Maybe because developers/maintainers are not paid by the hour, but mere > > volunteers, don't you think? > > So that means "free" software written and maintained by volunteers will > never be as > stable and secure as software that is written by people who are paid by > the hour. That is, > Debian software can *never* be as stable and secure as software that is > written and > maintained by people who are paid by the hour. Not only that, you are > saying if a Debian > user experiences a bug in Debian software, Debian developers/maintainers > do not have > to fix it. That's fine, but... > > If Debian developers/maintainers actively refuse to fix some bugs that > inevitably arise > by ignoring them, why would anyone depend on Debian software for anything > important? > > Best regards, > > Chuck > Date: Fri, 19 Aug 2022 18:54:07 -0400 > From: Chuck Zmudzinski <brchu...@netscape.net> > To: debian-user@lists.debian.org > Subject: Re: Why are some Debian bugs ignored for a long time? > Message-ID: <516ef004-8f6f-d790-e316-c1c85595d...@netscape.net> > Content-Language: en-US > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > On 8/19/2022 6:43 PM, Timothy M Butterworth wrote: > > > > > > On Fri, Aug 19, 2022 at 6:40 PM Chuck Zmudzinski <brchu...@netscape.net> > wrote: > > > > On 8/19/2022 6:20 PM, Timothy M Butterworth wrote: > > > > > > > > > On Fri, Aug 19, 2022 at 5:07 PM Chuck Zmudzinski < > brchu...@netscape.net> wrote: > > > > > > On 8/19/2022 4:44 PM, piorunz wrote: > > > > On 19/08/2022 18:57, Chuck Zmudzinski wrote: > > > > > > > > > I have noticed that some Debian bugs are ignored for a > long time, sometimes even when the person who submitted the bug offered a > patch. The Debian developers/maintainers sometimes don't even reply and > therefore never explain why the proposed patch cannot be applied. Why is > that the case with Debian developers/maintainers? > > > > > > > > Hi Chuck, > > > > > > > > Maybe because developers/maintainers are not paid by the > hour, but mere > > > > volunteers, don't you think? > > > > > > Debian Stable usually only ships security and stability patches. > > > > > > > > > So that means "free" software written and maintained by > volunteers will never be as > > > stable and secure as software that is written by people who > are paid by the hour. > > > > > > Freexian has developers that are paid by the hour to work on > Debian, anyone who wants with cash to spare can purchase some hours to have > work done on packages of their choosing. > > > > > > * 2 hours pack: 240 EUR + VAT (120 EUR/hour) > > > * 5 hours pack: 600 EUR + VAT (120 EUR/hour) > > > * 10 hours pack: 1150 EUR + VAT (115 EUR/hour) > > > * 20 hours pack: 2300 EUR + VAT (115 EUR/hour) > > > * 50 hours pack: 5500 EUR + VAT (110 EUR/hour) > > > > > > > That's good to know. Thanks. Presumably the work they do would be > contributed back > > to Debian for the benefit of all. I am curious if they would be able > to help in a case when > > a bug with a known fix has been ignored for a long time. I would > prefer that Debian would > > just fix the bug instead of having to pay someone to tell Debian > they should fix the bug. > > > > I could also just migrate to Fedora since their distro does not have > the bug and I wouldn't > > have to pay anyone for my system to work using Fedora. > > > > Distro hopping is one of the best things about Linux, I personally > switch between Debian, openSUSE and Fedora. One day I want to roll my own > distro. I am planning on making a stripped down debian focusing on KDE > Plasma and KDE Apps. One DE one hardware platform. > > Yes, the many distros is a nice thing about Linux, and now it looks like > it is time for > me to start hopping from Debian to other distros when necessary. > > Sorry, I forgot to reply-to the list, so I am bringing the discussion back > to the list. > > Thanks, > > Chuck > > > > > > > Best regards, > > > > Chuck > > > > > > > > > > > > > > > -- > > > ⢀⣴⠾⠻⢶⣦⠀ > > > ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system > > > ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ > > > ⠈⠳⣄⠀⠀ > > > > > > > > -- > > ⢀⣴⠾⠻⢶⣦⠀ > > ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system > > ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ > > ⠈⠳⣄⠀⠀ > Date: Fri, 19 Aug 2022 22:59:17 +0000 > From: Andy Smith <a...@strugglers.net> > To: debian-user@lists.debian.org > Subject: Re: Why are some Debian bugs ignored for a long time? > Message-ID: <20220819225917.joip5c5uw634a...@bitfolk.com> > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > Hello, > > On Fri, Aug 19, 2022 at 05:06:38PM -0400, Chuck Zmudzinski wrote: > > On 8/19/2022 4:44 PM, piorunz wrote: > > > On 19/08/2022 18:57, Chuck Zmudzinski wrote: > > > > I have noticed that some Debian bugs are ignored for a long time, > sometimes even when the person who submitted the bug offered a patch. The > Debian developers/maintainers sometimes don't even reply and therefore > never explain why the proposed patch cannot be applied. Why is that the > case with Debian developers/maintainers? > > > > > > Hi Chuck, > > > > > > Maybe because developers/maintainers are not paid by the hour, but mere > > > volunteers, don't you think? > > > > So that means "free" software written and maintained by volunteers will > never be as > > stable and secure as software that is written by people who are paid by > the hour. > > This is an assertion of your own that does not automatically follow > from what piorunz wrote. > > > That is, Debian software can *never* be as stable and secure as > > software that is written and maintained by people who are paid by > > the hour. > > This is also an assertion of your own that does not automatically > follow from what piorunz wrote. > > > you are saying if a Debian user experiences a bug in Debian > > software, Debian developers/maintainers do not have to fix it. > > That is a direct consequence of the meaning of the term "volunteer"; > you may as well have said, "water is wet". Volunteers cannot be > forced to do work, else they are not volunteers. > > > If Debian developers/maintainers actively refuse to fix some bugs that > inevitably arise > > by ignoring them, why would anyone depend on Debian software for > anything important? > > I would argue that the situation is similar (and often worse) in > every other free software project. > > I would also argue that while you may pay a software vendor to care > about your use case, that can also come with different issues. > > So really, life is not perfect, and we all do what we can to cope > with that. Things are not perfect in Debian nor elsewhere both > within and outside the free software world. > > I think I know some of the bugs that you are referring to as I keep > on eye on those developments. A gentle ping on the relevant bugs to > ask where things are may be appropriate. That's really the strongest > thing you can do. Others may be tempted to try to drag more info out > of you to determine what the exact history is here and who is > right/wrong, but I don't think that will help anyone in these > particular cases. > > Regards, > Andy > > -- > https://bitfolk.com/ -- No-nonsense VPS hosting > Date: Fri, 19 Aug 2022 16:13:02 -0700 > From: Samuel Wales <samolog...@gmail.com> > To: debian-user@lists.debian.org > Subject: must i consider zfs or lvm for smr large drive? > Message-ID: <CAJcAo8vyS=ifbBeOyenQVo2xtUxfLh-A_1RXGErXakkt4_= > p...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > apologies for the subject header being kind of an opinion poll rather > than a question. but it is meant as a question. > > > until now, i have avoided lvm and zfs determinedly. i have always > been completely satisfied to copy some big partition rather than deal > with the complexity of those. i don't want to get confused about them > when i am debugging or setting up. > > i use luks and ext4 and that's enough complexity for me. i get them > right, understand them, and glory in few corner cases. > > i have a new 4tb portable external drive. i want it to have a huge > partition. > > even such things as resizing sound error-prone or complex. more > layers and commands to learn. and zfs is a whole new thing, with, oh, > yeah, you have to use contrib or non-free [can i rely on this being > secure and also available into the future?] and oh, yeah, it's > different from luks, and oh, yeah, do a balance/resilver/whatever. > yes, send/recv beckons. > > but now i am thinking, with smr, the drive could pseudo-brick, despite > discard and fstrim. and i might then want to do some kind of, idk, dd > if=/dev/zero of=some-partition to "reset" it. and my 20gb root > partition might be too small for that. > > i don't actually know if /dev/zero resets smr to stop shuffling. i am > just speculating. > > but if it does, then i might want lvm's or zfs's resizing feature so > that i can do /dev/zero to some lo... gical ... volume? which would > then in my imagination reset smr and then the drive would work again > instead of 3.6tb filled non-writable. > > idk if zfs/btrfs has smr features better than ext4 or vice-versa. i > do NOT need snapshotting, raid. my box is old and would not support > deduplication and i wonder if it would even support zfs at all at 6gb > which always gets filled up with firefox. > > so, am i going to need one of these two > more-complex-than-luks-and-ext4 technologies just for safety when the > huge partition fills up? i know they are /desirable/ technologies for > those who like them. > > but desirability is not the question at all. :) the question is, for > MY case, is lvm/zfs/btrfs? going to be needed for smr. > > > idk if i am on this mailing list. > > preliminary comments below. :) > > > p.s. > > as a preliminarty comment, i have partitioned it for booting, my idea > being for it to boot off of anything for quick perfectly-my-env > rescue, not for all the time use. i ahve accessibility issues that > make installing and rescue cd's problematic.] > > as more preliminary, the thing does not boot on my old bios box no > matter what i try. > > and yet more preliminary, it is toshiba canvio basics. it does > spindown or head parking at a ridiculously low delay. idk if hdparm > -y or -Y or scsi-spin or scsiadd or eject or idle3 or what is safest. > or if i should let it rack up those smartctl attrs. > > and another. i am limited in computer use and have a very large > number of limitations that i cannot go into beause it would take too > much out of me to do so. i am not a normal kind of user. but i'd > still like gentle, helpful comments on my question if anybody has > some. i've seen issues with myself and others in the past [not on > this list] with "help" being used as a very transparent, quite obvious > excuse for being a rather extreme jerk, and i'd be interested in > knowing of some accepted things to say that say "thanks, but i do not > want 'help' from you personally at all but others are still very > welcome to contribute as i know already that they are sincere and > helpful" other than quitting the place entirely [at this point always > my best option]. the idea being to encourage sincere others to help > while getting others to realize i do not want help from the problem > person and that my not replying to the problem person does not mean > sincere others can't contribute, i/e/ the problem person has not > claimed accepted ownerhip over helping me and i am in no mood to be > attacked merely for asking a question or having accessibility and > other limitations or for no reason at all. > Date: Fri, 19 Aug 2022 20:20:21 -0400 > From: Chuck Zmudzinski <brchu...@netscape.net> > To: debian-user@lists.debian.org > Subject: Re: Why are some Debian bugs ignored for a long time? > Message-ID: <cd7bcbfd-45ab-967d-804b-0b4902d00...@netscape.net> > Content-Language: en-US > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 7bit > > On 8/19/2022 6:59 PM, Andy Smith wrote: > > Hello, > > > > On Fri, Aug 19, 2022 at 05:06:38PM -0400, Chuck Zmudzinski wrote: > > > On 8/19/2022 4:44 PM, piorunz wrote: > > > > On 19/08/2022 18:57, Chuck Zmudzinski wrote: > > > > > I have noticed that some Debian bugs are ignored for a long time, > sometimes even when the person who submitted the bug offered a patch. The > Debian developers/maintainers sometimes don't even reply and therefore > never explain why the proposed patch cannot be applied. Why is that the > case with Debian developers/maintainers? > > > > > > > > Hi Chuck, > > > > > > > > Maybe because developers/maintainers are not paid by the hour, but > mere > > > > volunteers, don't you think? > > > > > > > > you are saying if a Debian user experiences a bug in Debian > > > software, Debian developers/maintainers do not have to fix it. > > > > That is a direct consequence of the meaning of the term "volunteer"; > > you may as well have said, "water is wet". Volunteers cannot be > > forced to do work, else they are not volunteers. > > The fact that Debian is created by volunteers and therefore the chances are > high that users might run into problems and not get help from the > volunteers > who alone have the power to fix the problems is a fact that Debian users, > and > all users of free software, need to keep in mind. > > > > > > If Debian developers/maintainers actively refuse to fix some bugs that > inevitably arise > > > by ignoring them, why would anyone depend on Debian software for > anything important? > > > > I would argue that the situation is similar (and often worse) in > > every other free software project. > > In Linux itself, I think it is *much* better than in Debian. I am going to > try some other projects > and find out by experience where the consideration for the user has a > higher priority than in > Debian. > > > > > I would also argue that while you may pay a software vendor to care > > about your use case, that can also come with different issues. > > > > So really, life is not perfect, and we all do what we can to cope > > with that. Things are not perfect in Debian nor elsewhere both > > within and outside the free software world. > > > > I think I know some of the bugs that you are referring to as I keep > > on eye on those developments. A gentle ping on the relevant bugs to > > ask where things are may be appropriate.That's really the strongest > > thing you can do. > > I do that and I am ignored. I am not holding my breath waiting for a > response > from the relevant developers and maintainers. However, it would be a > pleasant > surprise if they *did* respond and I would be grateful if they did. I just > don't > think volunteers trying to help Debian but who ignore users who report bugs > in Debian is over the long term a good thing for Debian. > > > Others may be tempted to try to drag more info out > > of you to determine what the exact history is here and who is > > right/wrong, but I don't think that will help anyone in these > > particular cases. > > We agree on that point. > > Best regards, > > Chuck >
