On 2017-12-04 11:52:30 (+0100), Louigi Verona wrote: Probably. But do you really want to compare vendor lock-in with your personal problems with free software? Apples and oranges. Software has bugs. Your setup might as well. I had Ardour crash on me during a performance. Shit happens. I still use it ;-) Best, David -- https://sleepmap.de

On Mon, Dec 4, 2017 at 7:09 AM, Louigi Verona <louigi.verona(a)gmail.com> wrote: If you're serious about wanting some stolen laptop protection for Linux, I've used Prey for about 3 years. https://en.wikipedia.org/wiki/Prey_(software) That's not a ringing endorsement, since the laptops I use it on have not been stolen. I can only say that it hasn't gotten in my way, and that one of the computers goes for quite some time without being used and Prey occasionally notifies me "Hey, I haven't seen laptop so-and-so in a while... Do you know where your children are?" -- Kevin Cole, RHCE Team Contact Ubuntu Linux DC "LoCo" Washington, DC (US) GPG Key ID:0x3E696927

I am very serious, Neil. I am glad that your personal experience is different. You were able to build a system that works well for you. As a person who works a lot with multimedia, I can tell you that a proprietary video editor will be in most cases much more stable than a floss one. And why shouldn't it? Teams are working on it 40 hours every week, all year round. Nothing in the concept of FLOSS promises floss software to actually be more high quality or more stable. All it guarantees is that you can distribute it and modify. So why would it magically be more stable than proprietary? On Mon, Dec 4, 2017 at 1:09 PM, Neil C Smith <neilcsmith.net(a)googlemail.com> wrote: -- Louigi Verona https://www.patreon.com/droning https://louigiverona.com/

In my experience, an update can easily kill your system - and that happened to me more than once. And since I am not a customer, developers on the other end must not worry about what happens. I mean, nobody owes the user anything. "Fix it yourself, man". And it's fair. On Mon, Dec 4, 2017 at 1:28 PM, Neil C Smith <neilcsmith.net(a)googlemail.com> wrote: -- Louigi Verona https://www.patreon.com/droning https://louigiverona.com/

I would argue that when there is no customer relationship, updates can be more lax. I mean, I am working in the software industry. When someone is paying you and you know they are using your system for actual results, you are very careful with your updates. On Mon, Dec 4, 2017 at 1:40 PM, Neil C Smith <neilcsmith.net(a)googlemail.com> wrote: -- Louigi Verona https://www.patreon.com/droning https://louigiverona.com/

Microsoft and Apple are not the only examples of proprietary software, sir. And proprietary software developer is not necessarily a "corporation". In the end, it should not be a discussion of opinions (I agree with Louigi, I don't agree with Louigi), it should be a discussion with facts and statistics. There are areas of floss vs proprietary where stability and reliability are more or less the same. There are areas where proprietary clearly wins (video editors would be an obvious example). Maybe there are cases where floss is better that proprietary counterparts, although I have not seen a class of such examples. I have reacted to the initial post because a person was claiming that because *a problem* on a Mac happened - that means that everything which is a Mac is now a problem. I have responded that this does not sound very reasonable and that I can talk about *a problem* I had with Linux and apply the same logic. I think this rebuke was appropriate. Making sweeping generalizations about all Macs or about all proprietary software (or about floss, for that matter) based on isolated incidents is not an approach that will deliver an objective overview of the situation in the world of software. And, if I want to be pedantic, the initial post is an off-topic post anyway. It has little to do with LAU or LAD. On Tue, Dec 5, 2017 at 4:13 PM, A. P. Garcia <a.phillip.garcia(a)gmail.com> wrote: -- Louigi Verona https://www.patreon.com/droning https://louigiverona.com/

I can see what you are saying, Paul. That your typical bug is not as extensive as a lock-out of the whole machine. I still don't feel that it is fair to then conclude that Macs should not be used (at all). It is also possible that different systems will have different "typical complete system breakdown" problems, which will make them not so easy to compare. For instance, I buy an "Ubuntu-certified" machine. I come home and try to install Ubuntu on it. It turns out, Wi-Fi does not work, because this "certified" laptop requires special wifi drivers that Ubuntu does not have. Where do you get the necessary wi-fi drivers? Of course, on the Internet. So, my computer sat there for a day like a brick, until I could come to my office and connect through Ethernet. Or, Ubuntu Karmic came with no Ethernet at all. And when I went to Ubuntu IRC to ask what's up, one of the developers said "Who uses wired internet these days anyway?" To my knowledge this was never fixed. Additionally, Karmic had a video graphics problem and many users, including myself, would have their system randomly freeze up, with all work lost. So, I would say that these kind of experiences might also evoke a very emotional response, especially when you loose your work, etc. Is it comparable to what happened on a Mac? It could be. I do know that Macs typically do not lock out people. I have many-many friends who are using Macs for years and they have not had this problem. To Thorsten: *I have to note you have no statistics, either, but of course that doesn't stop you. It's as if you would ask for a level of sobriety, factuality and precision that you yourself refuse to offer, while pretending otherwise.* Your rebuke would be fair, but I don't think I ever pretended I had statistics at hand? I did offer a thought that if there is a customer relationship, then the software developer has more incentives and even obligations to make sure that critical errors do not happen. I do see that in the areas I am interested in this rule seems to work - I have mentioned video editors. It would actually be interesting to get some sort of stats there. OpenShot is universally known to be extremely volatile, for example. Each time I tried it - it crashes within 5-10 mins of usage. I tried many versions, including OpenShot 2. And then there is Windows Movie Maker, which reliably does not crash. But then the fact that we don't have stats for open source products reliability kind of hints to the fact that no QA is done anyway. Commercial companies typically have good stats on how reliable the program is. Because QA is done and statistics are collected. So, FLOSS might frequently be at a disadvantage. I think that these considerations might be a good basis of saying that reliability is not the result of releasing a program under GPL. This alone will not magically produce more reliability. Testing, QA does. It's as simple as that. " Anyway, ignoring the mood set with hyperbole like "... for I have sinned", going all pseudo-analytical instead, is rather tone-deaf." Yeah, maybe. I feel strongly about this. I might have chosen to just shut up, which is the course of action I typically take anyway. But on the other hand, I think that this discussion is quite contained and we all try to be polite and considerate. I definitely am far from being always careful and non-emotional, although I am trying to follow this path as much as possible! On Tue, Dec 5, 2017 at 6:30 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote: -- Louigi Verona https://www.patreon.com/droning https://louigiverona.com/

On Tue, 5 Dec 2017 17:21:05 +0100, Louigi Verona wrote: At least the software that runs on e.g. an Apple operating system could be from developers who are not associated with Apple. I'm using real-time audio software for iOS from a developer who tries to provide the same software for non-Apple tablet PCs, too, actually the only tablet PC platform that is suitable for professional audio usage is iOS. There is no such Linux based tablet PC platform available. Linux for our domain covers a very small market share. However, apart from this hardware related issue, a large amount of audio software isn't available for Linux. Good synth emulations are a proprietary domain of vendors who usually don't provide their software for Linux at all. Within the pro-audio domain there are sub-domains were comparison between Linux FLOSS and what ever kind of software for proprietary operating systems (also FLOSS or expensive closed source software) can't be compared, because for Linux a lot of software isn't available.

On Mon, Dec 4, 2017 at 10:52 AM Louigi Verona <louigi.verona(a)gmail.com> wrote: If, by stable, you mean what's broken stays broken, then I agree, ;-)

On Mon, Dec 4, 2017 at 6:09 AM, Neil C Smith <neilcsmith.net(a)googlemail.com> wrote: +1

On 12/04/2017 01:30 PM, Robin Gareus wrote: I was connected to my own phone hotspot. So unless it's a very low-level WLAN interface vulnerability, a local wireless exploit seems unlikely. I'm pretty sure the kill message did come from the iCloud (a service which I'm not using and which I don't indent to ever use) using the Find-my-Mac feature. I was _never_ given an option to opt out of this feature, and it was never made clear to me that I was carrying a time-bomb (with remote wipe option) that would enable unknown third parties to potentially cause five-digit damages on a whim. And re Luigi, no, I do not agree that proprietary is necessarily more stable. It can be, with proper engineering and human resources. Paying for the development of free software (which I regularly do) helps. But even though Mac OS X is a really slick operating system, a single feature like the one I encountered makes it completely and utterly unacceptable to me (and this is "just" Sierra, I hear with the latest High Sierra they are running absolutely hog-wild with respect to user choice and privacy). The day I move my private data into the Apple "cloud" (or rather, a content delivery network for celebrity porn), someone please kill me. Of Windows, I shall not speak, and I know what I'm not speaking of. Let me assure you I'm not this bearded hippie (well, yes I am, but...) whose main occupation in computing is trying out new window managers. I work with lots of different systems professionally, some of them ridiculously expensive and ridiculously closed, every day. That said, and very much in disagreement with Luigi, after being a long-time happy Thinkpad user _before_ the IME clusterfuck surfaced, I'm even tending towards "I will only ever accept those jobs that I can do with open software on open hardware". Still a pipe dream, but I've had it with big data and big company hypocrisy, and I will remove myself from it at the earliest opportunity, even if it means my creative possibilities will be severly limited. If creative freedom means having to play along with that shit, it's an illusion anyway and I want to be rid of it. Sorry for the noise, I did not expect this thread to go ballistic, and if it has bored anyone's socks off, my sincere apologies. -- Jörn Nettingsmeier De Rijpgracht 8, 1055VR Amsterdam, Nederland Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio), Tonmeister VDT http://stackingdwarves.net

On Mon, Dec 04, 2017 at 06:52:17PM +0100, Jörn Nettingsmeier wrote: OK :-) Simple fact is that if you want to be the master of your system then the only otions you have is Linux or one of the BSDs. And even then you need to be careful (with things like the Intel ME and similar). All the rest (including Android) is infested with telemetry, backdoors, and general surveillance stuff (usually sold as 'convenience'). Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Mon, Dec 04, 2017 at 11:52:30AM +0100, Louigi Verona wrote: Interesting that you mention carla. I wanted to give it a try some months ago. Until I noticed the list of dependencies, see e.g. <https://aur.archlinux.org/packages/carla/>. This 'Audio Plugin Host' depends on at least five GUI toolkits (ntk, gtk2, gtk3, qt4, qt5), a number of soft synths (why ?), and some very specific or -git versions of lots of libraries. Many of these have similar long dependency lists of their own. Expecting this sort of software to be stable, secure and maintainable (assuming you manage to build it at all) is just dreaming. This is not an uncommon problem with FLOSS. As someone who depends on open source audio SW for my daily work, I've learned to be very selective, even if that limits what I can use. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

Yes, that is possible and I wholeheartly lobby for that because library bugs and mismatches are common and could be avoided. Ardour does it and I do it in my own programs as well, or at least will if properly released. If you can copy a library into your source tree (Python in my case) why would depend to the external ecosystem? Some Linux distributions  (mostly very small and unknown though) do it already but the "way of forefathers", the shared library, is still stuck in peoples head. Bottom line: It turned out the Windows way of shipping all or most libs with the program is a really good way to compatibility. On 12/09/2017 02:24 PM, Louigi Verona wrote:

On 10.12.2017 11:51, Markus Seeber wrote: This is not related to Linux, but since someone already mentioned Windows.. I have bad news for you. See https://forum.juce.com/t/important-breaking-change-juce-will-now-use-dynami… Basically, with the latest updates, you can only load a maximum of 64 statically built plugins in a Windows DAW.

On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber < markus.seeber(a)spectralbird.de&gt; wrote: ​unortunately, several large toolkits of various types make this impossible because they themselves use dynamic (runtime-driven) loading of shared objects. GTK (and its dependency stack) is a particular offender there, but I believe the same is true of Qt. You can't statically link against this type of toolkit if your goal is to end up with a self-contained binary. the g* stack has made a few improvements in this area in recent years, but AFAIK it still isn't possible to build a self-contained binary. JUCE differs from this, I believe.​ ​

On Sun, Dec 10, 2017 at 08:37:08PM +0100, Markus Seeber wrote: So what would you write it in instead? -- Gordonjcp

On Sun, Dec 10, 2017 at 3:26 PM, Markus Seeber < markus.seeber(a)spectralbird.de&gt; wrote: ​You still need to ensure that the host can integrate with FLTK (or any other toolkit's) event loop. Without some explicit awareness, events etc. will never be delivered to the non-host toolkit.​ ​Not in any effective form. Their old version (more than a decade old) was based on *Motif* for X Window. There's a newer attempt at this, but it no notable benefits unless you wrote the host using the same thing, which is essentially impossible because of it's limited scope. ​ ​robtk is probably one of the most obvious answers, but even robin can identify some drawbacks. the thing is that on other platforms, there's a single event loop that all possible toolkits connect to. on Linux (X Window (and probably Wayland too)), this isn't true. Qt has done work to use the same glib-based event loop as GTK but this isn't a general solution. ​ On Windows or MacOS, it makes no difference what toolkit the host and plugin use, because everything is inevitably going to get routed through the same event loop (and redraw cycle). On Linux this is not true, and it's the root of most of these issues with plugins. ​

On 10.12.2017 22:14, Markus Seeber wrote: Carla has been doing this since it gained support for lv2 gtk2 UIs. Since Carla's backend does not rely on any toolkit, it can not show a toolkit based UI directly. For such plugins Carla opens the UI in a separate process, using a separate tool that supports that specific UI type. Messages to/from the main host are passed via pipes (which I now kinda regret going for, shared memory would be better) The exception to this are "external uis", but those do not take away the issue with symbol conflicts on shared libraries.

On Sun, Dec 10, 2017 at 09:26:55PM +0100, Markus Seeber wrote: That doesn't answer the question, really. For one thing, statically linking *anything* is utterly ridiculous and anyone doing that now or indeed at any point in the past 30 years of Unix development should have their hands cut off. Why would FLTK be any better than Gtk or Qt? It's slow, bloated and fairly ugly, and is yet another set of deps to pull in. -- Gordonjcp

On 12/12/2017 04:02 PM, Gordonjcp wrote: Keep in mind that audio plugins are not unix.

On Sun, 10 Dec 2017, Markus Seeber wrote: Often policy gets in the way of sensible. Some examples: - it would be sensible for debian packagers to include the "includes" with both the jackd1 and jackd2 packages rather than separating out to a *-dev package or at least name the jackd1 *-dev package so it can not be confused for use with jackd2. - it would be sensible if all plugins were packaged staticly linked but policy says otherwise. Audio production on Linux or for that matter on any OS, is a tiny portion of the total users which these policies are made for. Some distros may allow for exceptions to policy, but packaging already takes more effort than creating the software in the first place (at least the small utilities I have made so far), fighting some policy is just not worth it. I think this is one place where it is easier for the developer to supply a staticly linked set of files with a script to install them. The user can download them there rather than expecting their distro to "get it right". -- Len Ovens www.ovenwerks.net

On Sat, 9 Dec 2017 13:37:30 +0000 Gordonjcp &lt;gordonjcp(a)gjcp.net&gt; wrote: I rather thought it was library API changes that were breaking the software - something I've been a victim of. -- It wasn't me! (Well actually, it probably was) ... the hard part is not dodging what life throws at you, but trying to catch the good bits.

DLL Hell is something entirely different. The term comes from a time where Windows installers actually installed an applications required libraries in the "system location". So if application Foo is installed, and uses library Bar version N, but then you install application Baz, and it uses library B version N+M, suddenly Foo no longer works. Modern "application bundle" approaches don't do this, because they keep any required shared (i.e. non-statically linked) libraries private to the application (bundle). This is what MacOS has done since its inception, and it has never suffered from DLL Hell. The one notable downside is when there are vulnerabilities discovered in code ... the "traditional" Linux approach means that a system update can fix all applications in one step, whereas the bundle approach breaks this. On Sat, Dec 9, 2017 at 8:37 AM, Gordonjcp &lt;gordonjcp(a)gjcp.net&gt; wrote:

On Sat, 9 Dec 2017 11:36:28 +0000, Fons Adriaensen wrote: Regarding pacman.conf I planed to do the same back in 2015. I don't depend on open source audio for my daily work, but I want to have trouble free fun making music in my free time. To cut a long story short, I never used carla. Building caral and launching carla does work, I still wonder what Carla 1.9.7 (2.0-beta5) is for. Did I build the stable release 1.9.7 or a beta of 2.0? "source=("https://github.com/falkTX/Carla/archive/${pkgver}.tar.gz"" - https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=carla [rocketmouse@archlinux ~]$ grep carla /var/log/pacman.log [2015-08-28 10:17] [PACMAN] Running 'pacman -U carla-git-1.9.6.r239.g876cf81-2-x86_64.pkg.tar.xz' [2015-08-28 10:17] [ALPM] installed carla-git (1.9.6.r239.g876cf81-2) [2015-08-28 10:47] [PACMAN] Running 'pacman --color auto -U /tmp/yaourt-tmp-rocketmouse/PKGDEST.I9q/carla-bridges-win-2.0beta4-1-x86_64.pkg.tar.xz' [2015-08-28 10:47] [ALPM] installed carla-bridges-win (2.0beta4-1) [2017-01-07 12:07] [PACMAN] Running 'pacman --color auto -U /tmp/yaourt-tmp-rocketmouse/PKGDEST.nK0/carla-git-1.9.7.r10.g45f74421-1-x86_64.pkg.tar.xz' [2017-01-07 12:07] [ALPM] upgraded carla-git (1.9.6.r239.g876cf81-2 -> 1.9.7.r10.g45f74421-1) [2017-01-27 09:58] [PACMAN] Running 'pacman --color auto -U /tmp/yaourt-tmp-rocketmouse/PKGDEST.zYM/carla-bridges-win-2.0beta5.1-1-x86_64.pkg.tar.xz' [2017-01-27 09:58] [ALPM] upgraded carla-bridges-win (2.0beta4-1 -> 2.0beta5.1-1) [2017-07-21 16:55] [PACMAN] Running 'pacman --color auto -U /tmp/yaourt-tmp-rocketmouse/PKGDEST.W4q/carla-git-1:1.9.7b.r2.gc57e8169-2-x86_64.pkg.tar.xz' [2017-07-21 16:55] [ALPM] upgraded carla-git (1.9.7.r10.g45f74421-1 -> 1:1.9.7b.r2.gc57e8169-2) [2017-08-24 16:52] [PACMAN] Running 'pacman -Rss carla-bridges-win' [2017-08-24 16:53] [ALPM] removed carla-bridges-win (2.0beta5.1-1) [2017-08-24 16:53] [ALPM] removed carla-git (1:1.9.7b.r2.gc57e8169-2) [2017-08-24 17:06] [PACMAN] Running 'pacman --color auto -U /tmp/yaourt-tmp-rocketmouse/PKGDEST.b9O/carla-1.9.7-5-x86_64.pkg.tar.xz' [2017-08-24 17:06] [ALPM] installed carla (1.9.7-5) [rocketmouse@archlinux ~]$ pacman -Qi carla Name : carla Version : 1.9.7-5 Description : Audio Plugin Host Architecture : x86_64 URL : http://kxstudio.sf.net/carla Licenses : GPL2 Groups : None Provides : None Depends On : file fftw fluidsynth glu liblo linuxsampler mxml ntk-git projectm python python-pyqt5 qt5-svg zlib Optional Deps : gtk2: LV2 GTK2 UI support [installed] gtk3: LV2 GTK3 UI support [installed] python-pyliblo: OSC support [installed] python-rdflib: LADSPA-RDF support [installed] qt4: LV2 QT4 UI support [installed] zynaddsubfx: ZynAddSubFX banks [installed] Required By : None Optional For : None Conflicts With : None Replaces : None Installed Size : 96.42 MiB Packager : Ralf Mardorf &lt;ralf.mardorf(a)rocketmail.com&gt; Build Date : Thu 24 Aug 2017 05:03:44 PM CEST Install Date : Thu 24 Aug 2017 05:06:16 PM CEST Install Reason : Explicitly installed Install Script : No Validated By : None [rocketmouse@archlinux ~]$ carla qt5ct: using qt5ct plugin Using "qt5ct-style" theme Carla 1.9.7 (2.0-beta5) started, status: Python version: 3.6.3 Qt version: 5.9.3 PyQt version: 5.9.2 Binary dir: /usr/lib/carla Resources dir: /usr/share/carla/resources libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile qt5ct: D-Bus global menu: no libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile qt5ct: palette support is disabled libjack.so.0 loaded sucessfully! [snip]

On Sat, 9 Dec 2017 09:44:02 -0500, Paul Davis wrote: Do you think that Fons is an idiot, not being aware of this? The issue still remains, the more dedicated dependencies, the more possible issues. However, let's ignore the GUI issue, for what purpose are fluidsynth and linuxsampler dependencies of a host? Especially linuxsampler is a serious issue for a lot of distros, regarding the customized/invalid license. Actually the official Arch Linux community repository provides linuxsampler, but you unlikely could mention much more major distros supporting it by their official repositories. Keep in mind that some distro's, such as Arch Linux follow the KISS principle, IOW an app usually is build with the upstream defaults, without excluding features. This at least could become tricky, as soon as e.g. a dependency to Steinberg is involved. Maybe not regarding the distro's policy, but at least regarding hunting for the current Steinberg download link.

​No, I think you're the only person I've ever blocked email from​, so replying to me in this fashion goes unseen unless someone chooses to reply to your reply, which is mercifully infrequent. ​