When is enough, enough..?

Completely and utterly unrelated.

Moderators: raboof, MattKingUSA, khz

User avatar
Linuxmusician01
Established Member
Posts: 1503
Joined: Mon Feb 23, 2015 2:38 pm
Location: Holland
Has thanked: 734 times
Been thanked: 130 times

Re: When is enough, enough..?

Post by Linuxmusician01 »

Gps wrote: Tue Mar 21, 2023 3:51 pm

[...]
But no, lets add more features so that if I move my mouse to a corner of the screen, I see all opened windows.
Why ? :?

Because the Apple Macintosh had or has that too. A friend of mine used that as one of the reasons to explain why he likes MacOS better than Windows. He's on Windows now...

User avatar
Linuxmusician01
Established Member
Posts: 1503
Joined: Mon Feb 23, 2015 2:38 pm
Location: Holland
Has thanked: 734 times
Been thanked: 130 times

Re: When is enough, enough..?

Post by Linuxmusician01 »

bluzee wrote: Tue Mar 21, 2023 6:36 pm
Linuxmusician01 wrote: Tue Mar 21, 2023 11:43 am

Then there's applications like good ol' Mozilla Thunderbird that don't work properly no more with Google Contacts and G. Calendar.

I use Google Calendar with Thunderbird. Works fine. Its an extension that you have to add and setup. Contacts also has an extension but I don't use it with Thunderbird.

Gnome2 to Gnome3 was a bizarre time in history but without that Cinnamon probably wouldn't have happened and I love Cinnamon.

Yep. I always used Lightning at the time. But last time I tried T.bird it was harder to set up than before in my memoy, or my patience w/ T.bird is over, dunno. Jumping through hoops for sdometing that simple shouldn't be necessary IMHO. But my contacts not working properly is the one that forced me to stop using T.bird. The Contacts plugin that worked in the old days does not work anymore.

User avatar
GMaq
Established Member
Posts: 2768
Joined: Fri Sep 25, 2009 1:42 pm
Has thanked: 518 times
Been thanked: 555 times

Re: When is enough, enough..?

Post by GMaq »

Just to clarify...

I think on any platform we would all agree there have been favorite applications that have either been discontinued or have adapted new features and broken functionality or have been abandoned. This will happen anywhere there are individual and independent developers working on applications. Windows and MacOS are not immune at all to application developers behaving autonomously and changing their minds.. What I'm talking about in this thread is a level deeper than all that, I'm talking about (and obviously annoyed as hell with) the anarchy and disarray between the Kernel (which is managed incredibly well) and the applications, the actual Operating System stuff. The Kernel is quite incredible and as we here especially know the quality and number of applications for both Audio and Video have improved exponentially.. The problem is deeper than that, it is in the wheels and chassis so to speak, the vital bonds between the kernel and the applications that are unravelling and separating to what I feel is an unprecedented degree. To succeed this is a level where agreement, unity and established standards and protocols whether they are FLOSS or closed source shouldn't be changed easily without at least some sort of centralized debate, at least not if you expect and value any longevity and User retention..

As @khz said, for some the development and the ride on the bleeding edge is half the fun, watching it unfold in all it's anarchic glee... I totally understand that from an end-user perspective and it's very obvious that many of the members here are equally interested in 'playing computers' as 'playing music'. People breaking shit and laughing and picking up the pieces is all part of the fun (for some). However, when it comes to designing and putting together something for the people who just want to switch it on, have it behave predictably and make music without distraction the current state of Linux is extremely frustrating and what to keep and what to throw away are kind of important questions..

Last edited by GMaq on Wed Mar 22, 2023 4:32 pm, edited 1 time in total.
User avatar
bluzee
Established Member
Posts: 338
Joined: Mon Nov 30, 2020 11:43 pm
Has thanked: 18 times
Been thanked: 88 times

Re: When is enough, enough..?

Post by bluzee »

Well as I see it AVL is your system and you get to configure and customize it so that it suits your own personal situation and needs. It's great that once you are done you share it as it makes things very easy for us all. If people are unhappy with your choices that is not your problem. They can reconfigure after install or do their own thing entirely. You owe nothing to no one and that includes even releasing AVL at all.

Personally I really hope that you stick around. I really enjoy the chats with you.

Hard to predict the future of Linux especially with Microsoft now transitioning to it as well. Google's use of Linux has had pretty mixed results and I suspect Microsoft's involvement will just force dotnet snap packages on every one.

j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: When is enough, enough..?

Post by j_e_f_f_g »

One thing that definitely needs to change is that endusers must not support software that employs the behavior of viruses. In particular, I'm referring to any software that wedges itself between some lower level library, and the applications that use that library. That's the behavior of a computer virus. When JACK inserts itself between PulseAudio and your soundcard, to route PulseAudio through JACK, that's something a virus would do. When Pipewire replaces the PulseAudio and JACK libraries with its own versions that route audio through Pipewire, that's a computer trojan.

Endusers need to stop installing these viruses on their systems. Viruses can, and will, screw up the behavior of your system, and undoing that mess is akin to getting rid of a virus. It's a PITA, and sometimes your system is so f'ed up that you have to reinstall the entire thing. Pipewire should not even mess with apps that aren't specifically written to use it. Doing otherwise makes it a virus. Sure. what this means is that you can't simultaneously run an app that uses Pipewire, while running an app that uses something else (PulseAudio, Jack, Alsa). But at least you can be sure that, when you run each app, they will work as the developers designed them to work. But when a virus is in control on your system, there's no guarantee that an app will behave as it was designed.

If endusers resoundly reject things that behave like viruses, linux developers will stop writing them. Pipewire needs to be treated as the virus it is, until such time as the code which replaces jack and pulseaudio is completely removed and never employed. It's the only sane way to stop this rampaging runaway train from skidding off the rails.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

merlyn
Established Member
Posts: 1392
Joined: Thu Oct 11, 2018 4:13 pm
Has thanked: 168 times
Been thanked: 247 times

Re: When is enough, enough..?

Post by merlyn »

@GMaq

If you don't want to use Pipewire for AVL, just don't. I see no problem with that.

I think it's pretty reasonable and could be justified along the lines of ... With Pipewire in the first stage of development, Pipewire is not suitable for a stable distribution that is designed to work out of the box, or For AVL stable and mature software has been chosen, or Pipewire will be revisited in the future, but at the moment AVL is going to stay with a system that is known to work.

I don't use Pipewire, and I'm not inclined to try it at the moment. No real rational reason for that, simply that what I've got works, despite what jeffg says.

User avatar
MattKingUSA
Moderation Services Senior Administrator
Posts: 795
Joined: Fri Mar 21, 2008 4:01 pm
Location: United States
Has thanked: 52 times
Been thanked: 37 times
Contact:

Re: When is enough, enough..?

Post by MattKingUSA »

Pipewire works on some of my systems but have a system based on the Intel Celeron n5095 and it doesn't work. There's no noticable benefit to using pipewire. In fact the only dofference I have noticed is that audio is broken on some of my systems when it wasn't broken before. Lol

EDIT:

Oh by the way, creating /etc/modprobe.d/dspfix.conf with contents
options snd_intel_dspcfg dsp_driver=1

enables audio

and dmesg complains about SOF error without this fix.

-Matt :D

Gps
Established Member
Posts: 1116
Joined: Mon Mar 09, 2015 3:09 pm
Has thanked: 317 times
Been thanked: 112 times

Re: When is enough, enough..?

Post by Gps »

merlyn wrote: Thu Mar 23, 2023 3:41 pm

@GMaq

If you don't want to use Pipewire for AVL, just don't. I see no problem with that.

I think it's pretty reasonable and could be justified along the lines of ... With Pipewire in the first stage of development, Pipewire is not suitable for a stable distribution that is designed to work out of the box, or For AVL stable and mature software has been chosen, or Pipewire will be revisited in the future, but at the moment AVL is going to stay with a system that is known to work.

I don't use Pipewire, and I'm not inclined to try it at the moment. No real rational reason for that, simply that what I've got works, despite what jeffg says.

I think that Jeffg is referring to them not extending / fixing alsa, but instead adding another layer.
If we the users would not use it, pipewire might go away.
I am guilty of using pipewire though.
Although in general is does work, there are rumors it is causing something quite annoying with firefox.
(volume keeps resetting to 100%)

merlyn
Established Member
Posts: 1392
Joined: Thu Oct 11, 2018 4:13 pm
Has thanked: 168 times
Been thanked: 247 times

Re: When is enough, enough..?

Post by merlyn »

Gps wrote: Thu Mar 23, 2023 6:49 pm

I think that Jeffg is referring to ...

With me, it's more of a long standing thing, and a matter of principle. {thinks} Maybe I should use that for my signature.

JACK works! ...

j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: When is enough, enough..?

Post by j_e_f_f_g »

Gps wrote: Thu Mar 23, 2023 6:49 pm

Jeffg is referring to them not extending / fixing alsa, but instead adding another layer.

Actually, ALSA likely already does what these 3rd party wanna-be audio API's do. For example, did you know that ALSA already has the ability to mix/play the audio output of multiple simultaneously-running applications? You don't need JACK, Pulse, nor Pipewire to do that. ALSA has an audio mixer "plugin" called DMix that does this task.

So how do you enable it, and configure it? Nobody except the guy who wrote it really knows because he apparently can't be bothered to document it for others to use, like so much of ALSA. There's lots of stuff I uncovered when I did my audit of ALSA's source code. It's shocking really the amount of things that were never properly documented. That accounts for a good part of why devs keeps re-inventing "linux audio". They don't even realize they're duplicating functionality because they were never aware that such functionality even existed.

Nevertheless, linux audio wouldn't be such a chaotic mess if people simply wrote responsible third party software, that didn't do what it's not supposed to do. So what isn't application software supposed to do? It's not supposed to make low level, system wide changes to your operating system. For example, it's not supposed to be able to intercept the audio output of other app software, especially without the app having been designed to allow that. This is what viruses/trojans do -- not properly written 3rd party software. If Pipewire dared to even attempt to insert itself as a Windows system-wide audio API to for example surreptitiously capture the audio output of Skype, the next day MS would release a service pack that stopped pipewire dead in its tracks. And the next day, every virus suite would be updated to wipe Pipewire out of existence.

Ironically, only on linux would app developers get away with writing viruses and security vulnerabilities, and then have endusers actually gladly use them. Hell, XWindows is one of the biggest security holes ever deployed, and look how long linux folks have been using it. It's a good thing the OS has too miniscule an installed base to be worthwhile a target to criminal hackers. As soon as you install software not written by the kernel devs, you've gotten compromised.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

User avatar
GMaq
Established Member
Posts: 2768
Joined: Fri Sep 25, 2009 1:42 pm
Has thanked: 518 times
Been thanked: 555 times

Re: When is enough, enough..?

Post by GMaq »

j_e_f_f_g wrote: Fri Mar 24, 2023 3:51 pm

Actually, ALSA likely already does what these 3rd party wanna-be audio API's do. For example, did you know that ALSA already has the ability to mix/play the audio output of multiple simultaneously-running applications? You don't need JACK, Pulse, nor Pipewire to do that. ALSA has an audio mixer "plugin" called DMix that does this task.

That is pretty interesting. So I'm asking this not to be combative but out of curiousity, on Windows I can't and could never get any sort of usable recording performance without using the ASIO driver of my Audio device with the DAW. So is this also quasi-viral behavior? it's getting involved between the driver and the application too. These types of things seem to be the status quo for Pro Audio recording regardless of Platform in some way. I think throwing around the 'V' word is hyperbolic enough to obscure the good parts of your point TBH..

Side note: When I came to Linux I was astounded at how much bitching and whining there was about using JACK... I literally had it installed and working in 5 mins after simply installing the Packages back in 2006. Obviously effort was put into making it more streamlined for the next guy but to me it was simply a more well-rounded ASIO plus ReWire... How people could come from a system that required them to (a) separately install a driver for their Audio device and (b) explicitly select and enable the ASIO driver when they ran the DAW and then be completely bewildered about selecting an Audio device and starting JACK before launching the DAW on Linux is something I've never understood..

I personally suspect some of the reason Paul Davis eventually backed away from JACK with regards to Ardour was the ENDLESS amounts of questions on the Ardour Forums and IRC channel about using it and the fact that all major Distros strong-armed PulseAudio to the point it was unavoidable even on products like Ubuntu Studio... Seriously JACK on top of ALSA is really not that radically different than Windows+ASIO but ALSA+JACK+PulseAudio really just made figuring this mess out so confusing for new Users that JACK really couldn't sidestep it's reputation of being difficult even though in fairness it wasn't and it actually is/was superior to ASIO in numerous ways..

Last edited by GMaq on Sat Mar 25, 2023 11:58 pm, edited 1 time in total.
novalix
Established Member
Posts: 94
Joined: Wed Aug 11, 2021 1:12 pm
Has thanked: 6 times
Been thanked: 31 times

Re: When is enough, enough..?

Post by novalix »

dmix is part of libasound, which is a userspace libary on top of alsa as a kernel module. alsa itself does not handle more than one client at a time. there are good technical reasons why kernel side code does not bother with tracking multiple consumers. that is the realm of the userspace. that architectural design is in fact the same on windows and macos. "coreaudio" for example has only one name, but consists of two layers one layer of kernel code, which by itself just like alsa only accepts one client at a time and a userspace daemon which is this hardcoded client (that would be the "virus" in your little world).
one can use libasound to create a userspace daemon for sound processing. "apulse" resembles the pulseaudio api in that way. it is not very well suited for fast realtime processing and higher level abstractions. this is the reason why jackd, pulsaudio and now pipewire exist. they are extensions of alsa exactly how it is architecturally meant to be. if pipewire reaches its goals it will be a userspace daemon like the userspace part of coreaudio integrating realtime and "normal" desktop use cases. my two cents.

j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: When is enough, enough..?

Post by j_e_f_f_g »

GMaq wrote:

using the ASIO driver of my Audio device with the DAW. So is this also quasi-viral behavior? it's getting involved between the driver and the application too.

But the important part is: The application is written to specifically use ASIO. For example, ASIO can't intercept the audio output of an app using WASAPI. Nor can ASIO replace WASAPI's libraries with its own versions in order to redirect audio. Microsoft won't let that happen. If some sound server ever managed to do it, MS would label that a security breach, and a service pack would plug that hole.

Now it's true that you can write a "virtual driver" for Windows that redirects streams among the devices, but:

1) You have to do that in the kernel.
2) You have to register with the OS as a "filter driver", and the OS schedules your runtime, and does the actual transfer of data (I/O) to/from your driver.

So none of this insane no-holds-barred user-space "turf fight" over who gets what audio data like there is on linux.

dmix is part of libasound, which is a userspace libary on top of alsa

I consider libasound an inseparable part of ALSA. Other than Jack2, I know of no legitimate linux software which would dare attempt an endrun around libasound. That is the API of ALSA.

As such, it's not possible to equate libasound with these 3rd party daemons. You can't practically replace libasound without replacing ALSA en masse.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

novalix
Established Member
Posts: 94
Joined: Wed Aug 11, 2021 1:12 pm
Has thanked: 6 times
Been thanked: 31 times

Re: When is enough, enough..?

Post by novalix »

libasound defines the low-level api reference of the alsa kernel module, of course. this might be the reason, why every single higher level abstraction software that you call "3rd party" makes use of it (extends it).
one can be critical about the specific implementations for sure. but it would not be conceptually illegal to write even a whole new libasound-ng. that would be kind of bonkers, though.

User avatar
GMaq
Established Member
Posts: 2768
Joined: Fri Sep 25, 2009 1:42 pm
Has thanked: 518 times
Been thanked: 555 times

Re: When is enough, enough..?

Post by GMaq »

artix_linux_user wrote: Sun Mar 26, 2023 9:24 am

yes, and sorry, I cant read these stories about the user's pain when installing Ubuntu, or Debian....or what was it here, AVLinux?
Install Artix Linux and come back if you have any problems.
Don't take the long way home

The issues I'm talking about are not limited to Debian. Every single Linux Distro suffers the same fragmentation. My specific examples are because I'm experienced with Debian which is actually one of the better ones for not forcing an agenda by itself within the core organization. My daily system works wonderfully, I am almost unlimited (except for emerging tech not supported in Linux yet) to what I can do. The flavour of (Debian) Linux I use and work from (MX Linux) gives me a complete choice of systemd or sysvinit at every boot so if you think this is just about systemd it's not, luckily that at least is a non-issue with MX.. Artix gives me nothing but a new set of unknowns.. The thread is not about what system I use, it is about how the continuing and worsening fragmentation of Linux at the intermediate OS level across ALL of Linux makes preparing a product for OTHERS to use long term is become enough of a challenge that it requires some pause for thought about doing it..

Locked