Re: question about sound

[tomas]

On Fri, Aug 19, 2022 at 06:28:47AM +0100, mick.crane wrote:
> On 2022-08-18 08:39, to...@tuxteam.de wrote:

[...]

> > TBH you packed two questions into your original mail. Complaining that
> > most people concentrate on one is kinda... well ;-)
> 
> I don't mean to appear am complaining.

No sweat. I put a smiley on there, I was half-in-jest...

> Mention of teenage Guru was attempted humour.

...as you were, it seems :-D

> There were 2 question marks but really one question.
> "Is there a numpty's explanation what are these PulseAudio, Alsa, Jack?"
> Noticed had sound from the speakers when selecting Pulseaudio as Audio
> System but then doing that again I had no sound.

ALSA is the basic infrastructure: it includes the kernel drivers.

What Pulse and Jack provide is the "sound daemon", a user-space software
component which can mix sounds from different sources, and do other user
friendly (that's the intention, at least) things. For example overlaying
a warning sound from your desktop environment over the heavy metal you're
currently listening to, or remembering the settings for different output
hardware, or sending the sound over the network, or...

Jack focuses on low latency, which is especially important for musical
pros, where 20ms of latency do hurt.

> Have no idea what an Audio System is.
> I have found the Ardour6 manual.

Ardour uses one of the above back ends.

> The install system looks to have put me and pulse in audio group.
> Ardour manual is saying this is possibly not a good idea because only one
> person can access soundcard at a time.

This is the problem sound daemons try to solve. They sit on your sound
card and talk (hopefully) to the different applications.

> There may be an explanation why second attempt had no sound output because
> something had the soundcard because of user error.

There are many variables involved there: is your Ardour trying to talk
directly to the hardware and a sound daemon (pulse?) sitting on it?
Getting rid of the sound daemon or telling Ardour to talk to it might
solve the problem.

So to approach the thing, you'd have to look at your ardour's settings
*and* do a `ps' to search for your sound daemon (if any) *and* look
at its settings (pavuctrl is reportedly a front end to pulse -- I don't
know for sure, because I don't use it). And perhaps other things.

Yes, it's messy :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Cheat but no cheatsheets

[l0f4r0]

Hi,

18 août 2022, 22:42 de li...@tomgeorge.info:

> I installed cheat was describe as a quick way to check a command's options 
> instead of referring  to its man page.
>
> A great convenience but cheat list responds no cheatsheet found for list 
> instead listing available cheatsheets
>
> Is there a file of cheatsheets to download?
>
As you said you installed cheat, then you can type:
cht.sh :list

Without client, you need to use:
curl cht.sh/:list 

l0f4r0

Re: Cheat but no cheatsheets

[Curt]

On 2022-08-19, l0f...@tuta.io  wrote:
> Hi,
>
> 18 août 2022, 22:42 de li...@tomgeorge.info:
>
>> I installed cheat was describe as a quick way to check a command's options 
>> instead of referring  to its man page.
>>
>> A great convenience but cheat list responds no cheatsheet found for list 
>> instead listing available cheatsheets
>>
>> Is there a file of cheatsheets to download?
>>
> As you said you installed cheat, then you can type:
> cht.sh :list
>
> Without client, you need to use:
> curl cht.sh/:list 
>
> l0f4r0
>
>


 curl cheat.sh/:list

Or am I missing something once again, I wonder vaguely.

Re: question about sound

[Greg Wooledge]

On Thu, Aug 18, 2022 at 11:13:11PM -0500, David Wright wrote:
> The attraction of a one-liner is partly because of screens
> being around four times wider than high (characterwise).
> Wouldn't it be nice if bash had Perl's die ….

Some people put a die() function in their scripts, and then use it.

die() { printf >&2 '%s\n' "$*"; exit 1; }

Or variants thereof.  There are almost as many variations as there are
shell programmers.

Re: question about sound

[David]

On Fri, 19 Aug 2022 at 14:13, David Wright  wrote:
> On Thu 18 Aug 2022 at 06:58:20 (-0400), Greg Wooledge wrote:
> > On Wed, Aug 17, 2022 at 10:58:17PM -0500, David Wright wrote:
> > > $ type soxy
> > > soxy is a function
> > > soxy ()
> > > {
> > > [ -z "$1" ] && printf '%s\n' "Usage:${FUNCNAME[0]} 
> > > path-to/sound-file-of-any-type [trim 20 2]
> > > runs sox to play the file with any arguments given.
> > > The example above reminds you to put the full argument." 1>&2 && 
> > > return 1;
> > > local From="$1";
> > > shift;
> > > sox -q "$From" -t alsa default "$@"
> > > }
> >
> > Pedantic note: your error checking can fail.  If the printf fails for
> > some reason (e.g. because stderr has been closed, or is redirected to
> > a file on a file system that's full), the return won't execute.
>
> True—I guess I was willing to carry the risk. Thanks for noting that.
>
> > It's best just to use "if" in the normal way:
> >
> >   if [ -z "$1" ]; then
> > printf ...
> > return 1
> >   fi
> >
> > That way, the return will still be executed even if the printf fails.
> >
> > If you *insist* on using && because you think it's tres chic or something,
> > then you need to use a command group:
> >
> >   [ -z "$1" ] && {
> > printf ...
> > return 1
> >   }
> >
> > But this is not the recommended practice.
>
> Not so much très chic as bijou⁰. I can edit, eg
> [ -z "$Thepagecount" ] && printf '%s\n' "$1 has no pages!" ¹>&2 && return 1
> to
> [ -z "$Thepagecount" ] && { printf '%s\n' "$1 has no pages!" ¹>&2 ; return 1 
> ; }
> very easily. (I think I have about 350 such constructions in ~/.bash*.)
>
> The attraction of a one-liner is partly because of screens
> being around four times wider than high (characterwise).
> Wouldn't it be nice if bash had Perl's die ….

Hi David

Some further bash script thoughts ...

Considating hundreds of identical "printf '%s\n' 1>&2" constructs
into one function seems like it would remove a lot of visual noise,
and streamline reading and writing that code. My style would be:

msg_stderr() {
printf '%s\n' "$@" 1>&2
}

soxy() {
if [[ -z "$1" ]] ; then
msg_stderr "Usage:${FUNCNAME[0]}
path-to/sound-file-of-any-type [trim 20 2]
runs sox to play the file with any arguments given.
The example above reminds you to put the full argument."
return 1
fi
}

I find that style easier to read and reason about, but it would involve
more editing of your existing code.

Aside: I see that you are using ${FUNCNAME[0]}, so bash features
are acceptable. Using an array to pass the message lines to the
same function would preserve the code indentation, which
further improves readability for me.

soxy() {
if [[ -z "$1" ]] ; then
local m=(
"Usage:${FUNCNAME[0]} path-to/sound-file-of-any-type
[trim 20 2]"
"runs sox to play the file with any arguments given."
"The example above reminds you to put the full argument."
)
msg_stderr "${m[@]}"
return 1
fi
}

If you want to stay close to the oneliner style that you already
have, it could be done like this:

die() {
printf '%s\n' "$@" 1>&2
return 0
}

soxy() {
[[ -z "$1" ]] && die "message" && return 1
}

This avoids the issue of unexpected errors in printf, makes all
return values explicit, and avoids mixing && and || operators.
And hopefully not much trouble for you to edit, either :)

Re: Cheat but no cheatsheets

[l0f4r0]

Hi,

19 août 2022, 14:08 de cu...@free.fr:

> curl cheat.sh/:list
>
> Or am I missing something once again, I wonder vaguely.
>
`curl cht.sh/...` is quicker to type ;)

l0f4r0

Why are some Debian bugs ignored for a long time?

[Chuck Zmudzinski]

Hello,

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?

Best regards,

Chuck

Re: Raising volume past 100%

[David Griffith]

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?

Re: Why are some Debian bugs ignored for a long time?

[piorunz]

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?

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Re: Raising volume past 100%

[Cindy Sue Causey]

On 8/19/22, David Griffith  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 *

Re: Why are some Debian bugs ignored for a long time?

[Chuck Zmudzinski]

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

Re: Why are some Debian bugs ignored for a long time?

[Chuck Zmudzinski]

On 8/19/2022 6:43 PM, Timothy M Butterworth wrote:
>
>
> On Fri, Aug 19, 2022 at 6:40 PM Chuck Zmudzinski  
> wrote:
>
> On 8/19/2022 6:20 PM, Timothy M Butterworth wrote:
> >
> >
> > On Fri, Aug 19, 2022 at 5:07 PM 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?
> >
> > 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/
> ⠈⠳⣄⠀⠀

Re: Why are some Debian bugs ignored for a long time?

[Andy Smith]

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

must i consider zfs or lvm for smr large drive?

[Samuel Wales]

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.

Re: Why are some Debian bugs ignored for a long time?

[Chuck Zmudzinski]

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

Re: must i consider zfs or lvm for smr large drive?

[DdB]

hello,
idk if i got your question(1) right, but i am a zfs user since about 10
years and built my infrastructure around it.
But i would not use that for a single drive, as that would right from
the start have zfs not being able to do, what it is excellent at:
redundancy. Furthermore, zfs needs huge amounts of ram in order to run
reasonably fast (and even much more of it, i you want to use deduplication).

If i use it for a single drive, i would at the very least consider
setting "copies=2" to have at least some redundancy for data, i value.

But zfs has advantages, i love it, and it toook only several months of
getting used to it. Still: not in your case.

BTW: You did not state clearly (or i missed it), what exactly is your
goal you want to achieve by using zfs. It has - in short - 3 valuable
purposes: It is a software RAID, a volume manager and a filesystem, all
in one. If you just need a volume manager, lvm should do the trick.

Since you are using an encyption layer, you might be interested to know,
that zfs offers encryption since a few years too. I never used it, so
cannot say anything about it.

Re: must i consider zfs or lvm for smr large drive?

[David Christensen]

On 8/19/22 16:13, Samuel Wales wrote:

apologies for the subject header being kind of an opinion poll rather
than a question.  but it is meant as a question.





Please post:

# cat /etc/debian_version ; uname -a


What is the make and model of your computer?  BIOS or UEFI?


What is the make and model of your SMR drive?


What partition scheme do you use -- MBR or GPT?


How do you intend to use the partitions -- e.g. boot, swap, root, usr, 
var, home, data, online backup, offline backup, archives, images, 
sneakernet, other?



STFW "zfs smr disk drive":

* I see several reasonably current articles that advise against using 
ZFS with SMR drives; notably the Western Digital Red with SMR:


https://www.truenas.com/community/threads/update-wd-red-smr-drive-compatibility-with-zfs.88413/

https://arstechnica.com/gadgets/2020/06/western-digitals-smr-disks-arent-great-but-theyre-not-garbage/

* I see a 2014 OpenZFS conference paper regarding host-aware SMR.  I do 
not know if this technology made it into OpenZFS, or if Debian includes it:


https://openzfs.org/w/images/2/2a/Host-Aware_SMR-Tim_Feldman.pdf


STFW "btrfs smr disk drive", nothing stands out.


One option would be to benchmark all three choices (ext4, btrfs, zfs). 
Make sure to cover all the use-cases, including disaster recovery.



Another option would be to replace the disk with a CMR disk (e.g. 
refund, exchange, sale).



David

Re: must i consider zfs or lvm for smr large drive?

[David Christensen]

On 8/19/22 17:28, DdB wrote:


If i use [ZFS] for a single drive, i would at the very least consider
setting "copies=2" to have at least some redundancy for data, i value.



My SOHO file and backup servers are FreeBSD with encrypted ZFS root.  I 
use single 2.5" SSD's for the OS drive.  I hacked the installer to set 
copies=2 for boot and root, and enabled mirror for swap.



David

Re: debian-user-digest Digest V2022 #675

[STUART LENTON]

f o

On Sat, 20 Aug 2022, 8:28 am , 
wrote:

> Content-Type: text/plain
>
> debian-user-digest Digest   Volume 2022 :
> Issue 675
>
> Today's Topics:
>   Re: Raising volume past 100%  [ David Griffith  ]
>   Re: Why are some Debian bugs ignored  [ piorunz  ]
>   Re: Raising volume past 100%  [ Cindy Sue Causey
>Re: Why are some Debian bugs ignored  [ Chuck Zmudzinski
>Re: Why are some Debian bugs ignored  [ Chuck Zmudzinski
>Re: Why are some Debian bugs ignored  [ Andy Smith 
> ]
>   must i consider zfs or lvm for smr l  [ Samuel Wales <
> samolog...@gmail.com> ]
>   Re: Why are some Debian bugs ignored  [ Chuck Zmudzinski
>  Date: Fri, 19 Aug 2022 20:24:13 + (UTC)
> From: David Griffith 
> To: Bret Busby 
> cc: debian-user@lists.debian.org
> Subject: Re: Raising volume past 100%
> Message-ID: 
> 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 di

Re: Why are some Debian bugs ignored for a long time?

[Andy Smith]

Hi Chuck,

On Fri, Aug 19, 2022 at 08:20:21PM -0400, Chuck Zmudzinski wrote:
> On 8/19/2022 6:59 PM, Andy Smith wrote:
> > 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.

A danger here is that you write as if this is a particular problem
for Debian, but I think you've merely stated a truism for every
volunteer effort of any kind.

People do sometimes need reminding that they are relying on a
volunteer effort, however.

> 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 am not going to tell you that Debian is the best Linux
distribution for you or anyone specific, though you could perhaps
expect responses along those lines given that we're having this
conversation in a Debian space.

The thing is though, you can experience a problem within one project
that is frustrating and demotivating and so move to another project
that does not have that particular problem, only to later experience
a different problem in the next project that is also frustrating and
demotivating. Only you can decide which one overall suits you best;
what's certain is that nothing is going to be perfect.

If any Linux distribution were asked, "do you consider the user
experience to be a high priority?" they are probably all going to
answer, "yes!" But in reality there will always be some decisions
(or lack of decisions) made where some number of users feel they
were mistreated.

If you have the time and interest to look at other distributions
it's probably not going to be wasted time, anyway, if only to
compare and contrast.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Why are some Debian bugs ignored for a long time?

[Joe Pfeiffer]

Chuck Zmudzinski  writes:

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

This is equally true of commercial software: if the company feels it's a
low-enough impact bug it won't get fixed.

Commercial software has the additional risk that a product may simply
be withdrawn from the market.  With cloud-based commercial software,
this means it could completely fail to function (one that's particularly
noticeable is that as companies withdraw from the home automation space,
consumers are discovering their smart home has suddenly become
completely dumb).

Re: Why are some Debian bugs ignored for a long time?

[Chuck Zmudzinski]

On 8/19/2022 9:18 PM, Andy Smith wrote:
> Hi Chuck,
>
> On Fri, Aug 19, 2022 at 08:20:21PM -0400, Chuck Zmudzinski wrote:
> > On 8/19/2022 6:59 PM, Andy Smith wrote:
> > > 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.
>
> A danger here is that you write as if this is a particular problem
> for Debian, but I think you've merely stated a truism for every
> volunteer effort of any kind.
>
> People do sometimes need reminding that they are relying on a
> volunteer effort, however.
>
> > 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 am not going to tell you that Debian is the best Linux
> distribution for you or anyone specific, though you could perhaps
> expect responses along those lines given that we're having this
> conversation in a Debian space.
>
> The thing is though, you can experience a problem within one project
> that is frustrating and demotivating and so move to another project
> that does not have that particular problem, only to later experience
> a different problem in the next project that is also frustrating and
> demotivating. Only you can decide which one overall suits you best;
> what's certain is that nothing is going to be perfect.

Of course.

>
> If any Linux distribution were asked, "do you consider the user
> experience to be a high priority?" they are probably all going to
> answer, "yes!" But in reality there will always be some decisions
> (or lack of decisions) made where some number of users feel they
> were mistreated.
>
> If you have the time and interest to look at other distributions
> it's probably not going to be wasted time, anyway, if only to
> compare and contrast.
>
> Cheers,
> Andy
>

Thanks for the feedback, I do have the time to experiment with other distros 
and obviously I will use what best serves my goals. Debian still has the 
advantage that I have been using it for quite a while, have invested much time 
in tweaking it, and it still works fairly well for me. But at this point, I 
don't know if I will upgrade to bookworm or move to another distro before 
bookworm is released.

Best regards,

Chuck

Re: Raising volume past 100%

[David Griffith]

On Fri, 19 Aug 2022, Cindy Sue Causey wrote:

On 8/19/22, David Griffith  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.


For me, this problem seems to have started maybe six or seven years ago 
and has been getting progresively worse.  Maybe automated normalization 
could help, but that's something I'd rather not get into any time soon.



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

Re: question about sound

[David Wright]

On Fri 19 Aug 2022 at 08:46:29 (-0400), Greg Wooledge wrote:
> On Thu, Aug 18, 2022 at 11:13:11PM -0500, David Wright wrote:
> > The attraction of a one-liner is partly because of screens
> > being around four times wider than high (characterwise).
> > Wouldn't it be nice if bash had Perl's die ….
> 
> Some people put a die() function in their scripts, and then use it.
> 
> die() { printf >&2 '%s\n' "$*"; exit 1; }
> 
> Or variants thereof.  There are almost as many variations as there are
> shell programmers.

But if I have that, and:

soxy is a function
soxy () 
{ 
[ -z "$1" ] && die "Usage:  ${FUNCNAME[0]} path-to/sound-file-of-any-type 
[trim 20 2]
runs sox to play the file with any arguments given.
The example above reminds you to put the full argument.";
local From="$1";
shift;
sox -q "$From" -t alsa default "$@"
}

then typing just:

$ soxy

into an xterm will have the same effect as:

$ ^D

killing bash and the xterm, whereas what I would want from die is a
"double-return", quitting both die and soxy, and leaving me at:

$ 

just as Perl's die would do (if soxy was a Perl program).

On Fri 19 Aug 2022 at 22:53:24 (+1000), David wrote:
> If you want to stay close to the oneliner style that you already
> have, it could be done like this:
> 
> die() {
> printf '%s\n' "$@" 1>&2
> return 0
> }
> 
> soxy() {
> [[ -z "$1" ]] && die "message" && return 1
> }

I think that's the best we can do, unless I'm missing something.

Cheers,
David.

Re: Why are some Debian bugs ignored for a long time?

[tomas]

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 [...]
> >
> > Hi Chuck,
> >
> > Maybe because developers/maintainers are not paid by the hour, but mere
> > volunteers, don't you think?

There is another point: the package maintainer is very autonomous
in how (s)he does her thing. This has advantages and disadvantages.

There are processes in place for resolving such situations as when
a maintainer becomes unresponsive (perhaps (s)he has moved on to
other things, perhaps (s)he is in some situation of distress). Among
others, there is the NMU [0].

This question comes up regularly in this list. Had you searched
the archives, you'd found things like this [1] with advice (hint:
this would leave developers more time for fixing bugs ;-)

There is good advice by Jonathan Dowland in the linked thread on
how to do something about it. Want to give it a try?

> 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, of course, nonsense. This would be only the case if
the instance giving out the cash had an interest on the software
being "stable and secure". Most of the time they have an interest
on the software being sold, or on it generating cash flow via
other means (gathering user data, for that to be sold, for example).

So they will allocate their resources accordingly. I've worked
in the belly of big corps for a while and I assure you that my
boss wouldn't allow me to fix a bug unless (s)he could justify
to their bosses that the 1400 dollars "spent" on this are coming
back in some way.

Witness the whole history of Microsoft software with its incredible
ecosystem of malware, and you'll see how wrong your idea is :)

So each "world" has its upsides and (surprise!) its downsides.

That doesn't mean I wouldn't like to see projects like Debian
better funded, mind you. There are also people thinking about
this. There are companies which sponsor Debian, there are
companies which let employees work for Debian on their company
time; one seemingly successful example is Freexian [2], which
offers services by keeping alive older versions of Debian.

I get you want to contribute? 

;-)

Cheers

[0] https://wiki.debian.org/NonMaintainerUpload
[1] https://lists.debian.org/debian-user/2022/05/threads.html#00028
[2] https://www.freexian.com/services/debian-lts.html

-- 
t


signature.asc
Description: PGP signature

Re: question about sound

[tomas]

On Fri, Aug 19, 2022 at 11:55:33PM -0500, David Wright wrote:
> On Fri 19 Aug 2022 at 08:46:29 (-0400), Greg Wooledge wrote:
> > On Thu, Aug 18, 2022 at 11:13:11PM -0500, David Wright wrote:
> > > The attraction of a one-liner is partly because of screens
> > > being around four times wider than high (characterwise).
> > > Wouldn't it be nice if bash had Perl's die ….
> > 
> > Some people put a die() function in their scripts, and then use it.
> > 
> > die() { printf >&2 '%s\n' "$*"; exit 1; }
> > 
> > Or variants thereof.  There are almost as many variations as there are
> > shell programmers.
> 
> But if I have that, and:
> 
> soxy is a function
> soxy () 
> { 
> [ -z "$1" ] && die "Usage:${FUNCNAME[0]} 
> path-to/sound-file-of-any-type [trim 20 2]
>   runs sox to play the file with any arguments given.
>   The example above reminds you to put the full argument.";
> local From="$1";
> shift;
> sox -q "$From" -t alsa default "$@"
> }
> 
> then typing just:
> 
> $ soxy
> 
> into an xterm will have the same effect as:
> 
> $ ^D
> 
> killing bash and the xterm, whereas what I would want from die is a
> "double-return", quitting both die and soxy, and leaving me at:
> 
> $ 
> 
> just as Perl's die would do (if soxy was a Perl program).

The problem is... the function is running in your current shell's
process. This is totally different from the Perl case, where your
Perl programm gets its own process, so exit is going to do the
right thing (in both cases, the current process is terminated).

(Actually, Perl is more complicated, since you can catch a die
with an eval, so it is basically a full-fledged exception machinery).

I see two ways forward: either use return in your shell function;
you'd have to build your exception handling level-by-level, by
hand. Or do what everyone does and build your soxy as a command,
which will be executed in its own shell and not as a function.

You can set traps in the shell for exit and return events, so
you might try to build exception handling on that, but I don't
know whether it is a good idea. But possibly a nice exercise :)

Cheers
-- 
t


signature.asc
Description: PGP signature