[LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Jörn Nettingsmeier]

Here's me, having to deal with a 48 channel live recording over the
course of six shows. Since my MADI gear is kinda heavy and the rental
company had a Dante system on offer, I dusted off the 2013 Macbook pro I
bought used, purchased a Dante virtual soundcard license from Audinate
and happily tracked the first three shows with Ardour.

On the train on an off-day, I started a rough mix-down so that the
client can begin the selection process. In the middle of exporting, my
Mac shuts down and boots into a PIN unlock screen, telling me it has
been locked via "Find-my-Mac".

For the record, this Macbook had been purchased from a reputable large
online dealer, and it had been factory-reset and completely installed
from scratch.

The first thing I find as I frantically research this issue (on my
proper laptop, that is controlled by me, not by some iFuckwits), is that
this iFeature even contains the option of a remote data wipe.
My excuses to my fellow passengers who got in the way of a stream of
expletives suddenly bursting forth from an otherwise unobtrusive
business traveller, as said traveller notices he doesn't have a
screwdriver to yank his data drive out of this ransomware machine, and
cannot even be sure it's off when it says it's off because of course the
battery cannot be removed without major surgery, either.

Was able to salvage the data at home using a real operating system on
real hardware, and today I'm going to find an authorized mac reseller
and give the guy at the guru bar a day he will remember and testify
about at the next Apple employee incentive day.

Long story short: don't.

[David Runge]

Post by Jörn Nettingsmeier
Long story short: don't.

Holy...

Glad you got your data at least. This would also freak me out a lot...

[Albert Graef]

On Mon, Dec 4, 2017 at 10:37 AM, Jörn Nettingsmeier <

Post by Jörn Nettingsmeier
Long story short: don't.

Holy cow.

I like funny war stories like these. Of course it's only funny if you're
not bitten yourself. :( I feel with you.

At least you got a 2013 MB which is still half-decent hardware compared to
the fancy shiny thingies they sell for premium prices these days. Where you
can gain root without a password and need a USB-C dongle of substantial
size to connect to just about *any* kind of useful, non-snowflake
peripheral. Well, at least it connects to your power supply, isn't that
great? :)

Take care,
Albert

[Louigi Verona]

You realize, of course, that this is probably a bug and that this was not
intended by Apple? You should also understand that millions of people are
using Macs everyday and their data doesn't get lost, right?

Because, if not, I can supply many-many stories where I would loose data
because of stupid Linux machines, lose gigs because suddenly the music
software wouldn't start, although it did just yesterday. There are enough
problems that stem from software not having an owner that from it "being
controlled" by someone else. And then after bashing Linux, I can finish my
email with a dramatic "don't".

Any system can fail, and it is never at the right time. And in my
experience, proprietary systems are generally much more stable than floss,
and are less likely to fail suddenly and without warning.

For instance, when preparing for the Sonoj convention, I had Carla start
crashing on me and I could not complete music examples. I eventually had to
revert to FLStudio to make them.

At the Sonoj Convention, 10 minutes before my dj set, Mixxx has deleted all
of my tracks library and I had to frantically search for a fix. I found a
workaround, but could not include a couple of new tunes into the set.

Did I write a post blaming floss for that? No.

Post by Albert Graef
On Mon, Dec 4, 2017 at 10:37 AM, Jörn Nettingsmeier <

Post by Jörn Nettingsmeier
Long story short: don't.

Holy cow.
I like funny war stories like these. Of course it's only funny if you're
not bitten yourself. :( I feel with you.
At least you got a 2013 MB which is still half-decent hardware compared to
the fancy shiny thingies they sell for premium prices these days. Where you
can gain root without a password and need a USB-C dongle of substantial
size to connect to just about *any* kind of useful, non-snowflake
peripheral. Well, at least it connects to your power supply, isn't that
great? :)
Take care,
Albert
--
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
WWW: https://plus.google.com/+AlbertGraef
_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[David Runge]

Post by Louigi Verona
You realize, of course, that this is probably a bug and that this was not
intended by Apple? You should also understand that millions of people are
using Macs everyday and their data doesn't get lost, right?

Probably.

But do you really want to compare vendor lock-in with your personal
problems with free software?
Apples and oranges.

Post by Louigi Verona
Because, if not, I can supply many-many stories where I would loose data
because of stupid Linux machines, lose gigs because suddenly the music
software wouldn't start, although it did just yesterday. There are enough
problems that stem from software not having an owner that from it "being
controlled" by someone else. And then after bashing Linux, I can finish my
email with a dramatic "don't".
Any system can fail, and it is never at the right time. And in my
experience, proprietary systems are generally much more stable than floss,
and are less likely to fail suddenly and without warning.
For instance, when preparing for the Sonoj convention, I had Carla start
crashing on me and I could not complete music examples. I eventually had to
revert to FLStudio to make them.
At the Sonoj Convention, 10 minutes before my dj set, Mixxx has deleted all
of my tracks library and I had to frantically search for a fix. I found a
workaround, but could not include a couple of new tunes into the set.
Did I write a post blaming floss for that? No.

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

[Louigi Verona]

Proprietary software does not automatically mean vendor lock-in. A function
to block stolen laptops has nothing to do with vendor lock-in. It is a
useful feature that, frankly, I would love to have on Linux as well.

But also no, I did not compare free software and vendor lock-in. I compared
the problems generated by both of these situations. And that if on the
basis of a problem with proprietary software the OP seemed to be ok with
saying "don't" to the whole proprietary system (that works very-very well
99.9% of the time), then consistently applied such an approach should lead
him to say "no" to all of Linux as well.

Post by David Runge

Post by Louigi Verona
You realize, of course, that this is probably a bug and that this was not
intended by Apple? You should also understand that millions of people are
using Macs everyday and their data doesn't get lost, right?

Probably.
But do you really want to compare vendor lock-in with your personal
problems with free software?
Apples and oranges.

Post by Louigi Verona
Because, if not, I can supply many-many stories where I would loose data
because of stupid Linux machines, lose gigs because suddenly the music
software wouldn't start, although it did just yesterday. There are enough
problems that stem from software not having an owner that from it "being
controlled" by someone else. And then after bashing Linux, I can finish

my

Post by Louigi Verona
email with a dramatic "don't".
Any system can fail, and it is never at the right time. And in my
experience, proprietary systems are generally much more stable than

floss,

Post by Louigi Verona
and are less likely to fail suddenly and without warning.
For instance, when preparing for the Sonoj convention, I had Carla start
crashing on me and I could not complete music examples. I eventually had

to

Post by Louigi Verona
revert to FLStudio to make them.
At the Sonoj Convention, 10 minutes before my dj set, Mixxx has deleted

all

Post by Louigi Verona
of my tracks library and I had to frantically search for a fix. I found a
workaround, but could not include a couple of new tunes into the set.
Did I write a post blaming floss for that? No.

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

[Kevin Cole]

Post by Louigi Verona
Proprietary software does not automatically mean vendor lock-in. A function
to block stolen laptops has nothing to do with vendor lock-in. It is a
useful feature that, frankly, I would love to have on Linux as well.

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

[Neil C Smith]

And in my experience, proprietary systems are generally much more stable
than floss, and are less likely to fail suddenly and without warning.

ha ha ha ha ha ha ha .... oh, wait .. you're serious?! ;-)

There's a reason I use FLOSS, and it's because my personal experience is
absolutely the opposite of this.

Best wishes,

Neil

[Louigi Verona]

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?

Post by Neil C Smith

And in my experience, proprietary systems are generally much more stable
than floss, and are less likely to fail suddenly and without warning.

ha ha ha ha ha ha ha .... oh, wait .. you're serious?! ;-)
There's a reason I use FLOSS, and it's because my personal experience is
absolutely the opposite of this.
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

[Neil C Smith]

Hi,

Post by Louigi Verona
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?

No, I get you're serious - more amused by how different your experience is
to my own - I'm sure I can crash a Mac by looking at them. ;-) I'm not
necessarily saying that there aren't problems, but that it's far less
likely in my experience that a FLOSS system that's working solidly one day
will behave differently the next.

But actually there is something in FLOSS that I think does sometimes make
for more stable software, if less featured - there's no money to be made in
fixing bugs.

Mind you, my usual response to anyone asking me why I work with FLOSS is
that I got fed up of paying for software that doesn't work properly - we've
got all our own shit that doesn't work properly, but at least I don't feel
like I've been screwed over. ;-)

Best wishes,

Neil

[Louigi Verona]

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.

Post by Neil C Smith
Hi,

Post by Louigi Verona
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?

No, I get you're serious - more amused by how different your experience is
to my own - I'm sure I can crash a Mac by looking at them. ;-) I'm not
necessarily saying that there aren't problems, but that it's far less
likely in my experience that a FLOSS system that's working solidly one day
will behave differently the next.
But actually there is something in FLOSS that I think does sometimes make
for more stable software, if less featured - there's no money to be made in
fixing bugs.
Mind you, my usual response to anyone asking me why I work with FLOSS is
that I got fed up of paying for software that doesn't work properly - we've
got all our own shit that doesn't work properly, but at least I don't feel
like I've been screwed over. ;-)
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

[Neil C Smith]

Post by Louigi Verona
In my experience, an update can easily kill your system - and that
happened to me more than once.

Yes, and that happens everywhere, not specific to FLOSS. This is about
triaging when and which updates you apply to a working system. And
something for developer to keep in mind too - separation of concerns for
security fixes, bug fixes and features.

Best wishes,

Neil

[Louigi Verona]

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.

Post by Neil C Smith

Post by Louigi Verona
In my experience, an update can easily kill your system - and that
happened to me more than once.

Yes, and that happens everywhere, not specific to FLOSS. This is about
triaging when and which updates you apply to a working system. And
something for developer to keep in mind too - separation of concerns for
security fixes, bug fixes and features.
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

[A. P. Garcia]

Post by Louigi Verona
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.

nope nope nope. I work in IT, and we got burned one too many times by
applying patches on Microsoft's patch Tuesday, so we moved our patch
night back a week. Let other people be Redmond's guinea pigs.

[Louigi Verona]

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.

Post by A. P. Garcia

Post by Louigi Verona
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

Post by Louigi Verona
are very careful with your updates.

nope nope nope. I work in IT, and we got burned one too many times by
applying patches on Microsoft's patch Tuesday, so we moved our patch
night back a week. Let other people be Redmond's guinea pigs.
_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[Paul Davis]

Post by Louigi Verona
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.

​That's not really a fair summary. The *problem* which occured on a Mac
potentially involved a complete lockout of the entire machine, for all
time.​ It wasn't a bug in piece of software, it wasn't a crash during a
live performance. It was the successful operation of a feature designed to
take away all control of the machine from the person using it.

It's entirely reasonably to say that you don't mind this feature, and
consider its existence to be a net positive rather than a net negative.

But you can't draw equivalence between this behaviour and some arbitrary
"problem" on any other system.

Exception: if it could be shown that Joern's experience was the result of a
bug OR was easily reversible, then this would put the experience back into
the same realm as other arbitrary system-specific "problems".

​

[Louigi Verona]

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!

Post by Paul Davis

Post by Louigi Verona
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.

​That's not really a fair summary. The *problem* which occured on a Mac
potentially involved a complete lockout of the entire machine, for all
time.​ It wasn't a bug in piece of software, it wasn't a crash during a
live performance. It was the successful operation of a feature designed to
take away all control of the machine from the person using it.
It's entirely reasonably to say that you don't mind this feature, and
consider its existence to be a net positive rather than a net negative.
But you can't draw equivalence between this behaviour and some arbitrary
"problem" on any other system.
Exception: if it could be shown that Joern's experience was the result of
a bug OR was easily reversible, then this would put the experience back
into the same realm as other arbitrary system-specific "problems".
​

[Thorsten Wilms]

On 05.12.2017 17:21, Louigi Verona wrote:

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.

Post by Louigi Verona
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.

For a person of such eloquence, it seems strange that your reading
comprehension would fail you so terribly or that you would suddenly try
your hardest to be the opposite of pedantic.

Jörn's post was an openly emotional reaction to a situation that came
about because of a specific set of features that you get with an Apple
laptop, if you want them, or not. It's a fact that there is a specific
risk because of those features. So if you are that hell-bent on boiling
it down, the statement would be: "There is a specific problem with every
(since a certain generation) Apple laptop".

Anyway, ignoring the mood set with hyperbole like "... for I have
sinned", going all pseudo-analytical instead, is rather tone-deaf.

I for one, consider the case interesting and the way it was brought
forward entertaining. My thanks to Jörn, who doesn't deserve such
persnicketiness!

[Ralf Mardorf]

Post by Louigi Verona
Microsoft and Apple are not the only examples of proprietary software,
sir. And proprietary software developer is not necessarily a
"corporation".

At least the software that runs on e.g. an Apple operating system could
be from developers who are not associated with Apple.

Post by Louigi Verona
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.

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.

[nils]

These are all just anecdotes. If there is a bug please report or fix it.
If it is a conceptual problem that leads to misbehaviour please discuss
here specific solutions to specific problems.

Otherwise this will just be a thread with "But me..." and "But I..."
back and forth.  Keep that for LAU, please.

Nils

[Kevin Cole]

And in my experience, proprietary systems are generally much more stable
than floss, and are less likely to fail suddenly and without warning.

If, by stable, you mean what's broken stays broken, then I agree, ;-)

[Len Ovens]

And in my experience, proprietary systems are generally much more
stable than floss, and are less likely to fail suddenly and without
warning.
ha ha ha ha ha ha ha .... oh, wait .. you're serious?! ;-)
There's a reason I use FLOSS, and it's because my personal experience is
absolutely the opposite of this.

+1, our family has started out with a number of windows machines (mostly
laptops) and my wife has said she wanted to keep the windows in there.
That normally lasts about a week before I get "put what you have in my
computer please". This from someone who uses their computer for browsing,
skype, and word processing.

I can't talk about Macs, they are out of our price range.

It is unfortunate that some of the big players in the Linux world have
decided "covergence" is a good thing. I really, really, do not want my
desktop/laptop to work like a 5inch phone thank you very much. I actually
do work on my machine. Thankfully, Linux does offer more than one DE and
one can find work helpers buried, but still there if they need to.

I have worked in a large company who used windows as the corperate system
because there was someone to sue if things broke too badly. At the time
the microvax was still used for realtime stuff (machine control) with NT for
data massaging. However, the install disks we were supplied with (to
install NT) were all basic linux on a cd with dd to install the image. We
also found that most trouble shooting was best done with a linux rescue
disk. Backups were all done with a linux dd too. Do note, I have been away
from the technical end for over 10 years now (it let me move out of the
Vancouver area and onto Vancouver Island and less than 1 hour to get to
work for 2 hours saved a day) and I know there are new machines that have
been installed. I am sure they do not use MicroVax as there is no one
around to sue if it quits but I do not know what they do use. There was
some experimenting with Red Hat by the IT department (remember someone to
sue, and this company is big enough that they did use lawsuit as a
negotiating tool - often).

My experience with proprietary software as someone whos job is to keep
things running has been if it's broken... live with it somehow. Even the
smallest SW fix was $10k so they weren't done often and then only when the
fixes were a list, never a single bug. In older times, the machine control
SW was written in house, well understood and fixed as needed.

I also remember the days when hardware automatically came with a full
schematic.

--
Len Ovens
www.ovenwerks.net

[A. P. Garcia]

On Mon, Dec 4, 2017 at 6:09 AM, Neil C Smith

Post by Neil C Smith

And in my experience, proprietary systems are generally much more stable
than floss, and are less likely to fail suddenly and without warning.

ha ha ha ha ha ha ha .... oh, wait .. you're serious?! ;-)
There's a reason I use FLOSS, and it's because my personal experience is
absolutely the opposite of this.

+1

[Robin Gareus]

Post by Louigi Verona
You should also understand that millions of people are
using Macs everyday and their data doesn't get lost, right?

I actually don't know a Mac user who hasn't been burnt and they all use
TimeCapsules or iCloud or dropbox or a similar backup solution.

I've seen a many master-students who are writing their thesis on OS X to
send it to themselves or friends by email every other hour as backup.
Only few of them embraced git, because sending an email is just too trivial.


Anyway Joern's story is not about loosing files, but being locked out of
the machine (!).

Seeing as this was in a train, and last I looked the DB-network was wide
open, I'm curious if this was actually a hack by guy in another
train-compartment or perhaps a subverted access-point exploiting some OS
X vulnerability.

Post by Louigi Verona
Because, if not, I can supply many-many stories where I would loose data
because of stupid Linux machines, lose gigs because suddenly the music
software wouldn't start, although it did just yesterday. There are enough
problems that stem from software not having an owner that from it "being
controlled" by someone else. And then after bashing Linux, I can finish my
email with a dramatic "don't".
Any system can fail, and it is never at the right time. And in my
experience, proprietary systems are generally much more stable than floss,
and are less likely to fail suddenly and without warning.
For instance, when preparing for the Sonoj convention, I had Carla start
crashing on me and I could not complete music examples. I eventually had to
revert to FLStudio to make them.
At the Sonoj Convention, 10 minutes before my dj set, Mixxx has deleted all
of my tracks library and I had to frantically search for a fix. I found a
workaround, but could not include a couple of new tunes into the set.
Did I write a post blaming floss for that? No.

I very much hope you did file bug reports for all those issues.


While the end-result may be the same: "fail to deliver result". Joern's
experience is quite different from what you describe.

Also note that all the software that you have mentioned comes with a
disclaimer (GPL):

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

..writing a blaming blog post is a non-starter if you accept the license.

2c,
robin

[Jörn Nettingsmeier]

Post by Robin Gareus
Seeing as this was in a train, and last I looked the DB-network was wide
open, I'm curious if this was actually a hack by guy in another
train-compartment or perhaps a subverted access-point exploiting some OS
X vulnerability.

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.

[Robin Gareus]

Post by Jörn Nettingsmeier

Post by Robin Gareus
Seeing as this was in a train, and last I looked the DB-network was wide
open, I'm curious if this was actually a hack by guy in another
train-compartment or perhaps a subverted access-point exploiting some OS
X vulnerability.

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.

It's probably all in some EULA smallprint, and your visit to the
Apple-store will be rather unspectacular.

You said earlier "[the macbook] had been factory-reset and completely
installed from scratch." According to the doc, clearing the NVRAM or
PRAM should disable "Find-My-Mac". Then again, since any Apple-store can
un-brick it if you show them a proof-of-purchase, there's yet another
backdoor...

Anyway, I'm glad you were able to get all the data from it.
May I ask how? http://www.system-rescue-cd.org/ ?

Cheers!
robin

PS. As atonement for your sin, I suggest hosting the next Linux Audio
Conference ;-))

[Fons Adriaensen]

Post by Jörn Nettingsmeier
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.

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,

[Ralf Mardorf]

Post by Louigi Verona
Any system can fail, and it is never at the right time. And in my
experience, proprietary systems are generally much more stable than
floss, and are less likely to fail suddenly and without warning.

I made that good experiences with audio software on an iPad 2, that I
consider to drop more Linux audio software and buy better Apple
equipment to migrate to more proprietary audio software. I'm still
uncertain, since there's one big issue. If an Apple device is
discontinued, as e.g. the iPad 2 and you should experience a bug, as I
do for SampleTank, it seems to be strategy of the software developers
to expect that you upgrade the Apple hardware, instead of fixing the
bug for "old" Apple hardware. I try to use old computers as long as
possible, even if I should have the money to buy new hardware. With
Linux an old PC easily could be used for a decade and if somebody
doesn't want to do this, it's not expensive to get a new PC. Apple, as
well as the software developers seem to expect that users buy a new
Apple computer each year or at least after three years. IMO this is a
bad attitude, but even if I wouldn't care about the attitude, usually I
don't have the money to pay for Apple hardware. I won the iPad 2 when
I had no money and fortunately I've got the money to pay for Apple
hardware nowadays, but this might change in the future. Btw. I don't
use iCloud, but I could imagine that Apple in the future dose enforce
iCloude usage, e.g. to store and restore purchases.

[Fons Adriaensen]

for instance, when preparing for the sonoj convention, i had carla start
crashing on me and i could not complete music examples. i eventually had to
revert to flstudio to make them.

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,

[Louigi Verona]

This is a good point, Fons.

On Windows it is typical to bundle a program with stable libraries and
dependencies. Is this strategy thinkable on FLOSS systems?

[nils]

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.

Post by Louigi Verona
This is a good point, Fons.
On Windows it is typical to bundle a program with stable libraries and
dependencies. Is this strategy thinkable on FLOSS systems?
_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[Markus Seeber]

Post by nils
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.

No the "way of forefathers" was static linking.

Post by nils
Bottom line: It turned out the Windows way of shipping all or most
libs with the program is a really good way to compatibility.

Just employ static linking when sensible. There are less ways a linker can screw that up
during runtime and your application size will be even smaller since we have link time
optimization these days, startup time will be faster and run time may be faster.
Sure, if LGPL licensed libraries are used, this may be impossible but from a technical
standpoind dynamic linking for self containing application bundles does not make
sense unless you actually need to link dynamically (e.g. license requirements, plugins etc.).

The current way of bundling shared libraries with the application ist just a dirty workaround
for Problems that combines the worst parts of static and dynamic linking,
introduces bloat and solves problems that are mostly caused by employing dynamic
linking in the first place.

Yes I understand why people do it, yes it works and yes it solves social and resource problems
so that people can move on. But the real technical problem is not solved.

Post by nils

Post by Louigi Verona
This is a good point, Fons.
On Windows it is typical to bundle a program with stable libraries and
dependencies. Is this strategy thinkable on FLOSS systems?
_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev

_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[Filipe Coelho]

Post by Markus Seeber

Post by nils
Bottom line: It turned out the Windows way of shipping all or most
libs with the program is a really good way to compatibility.

Just employ static linking when sensible.
...
The current way of bundling shared libraries with the application ist just a dirty workaround
for Problems that combines the worst parts of static and dynamic linking,
introduces bloat and solves problems that are mostly caused by employing dynamic
linking in the first place.

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-dynamic-linking-for-the-windows-runtime-by-default/25276

Basically, with the latest updates, you can only load a maximum of 64
statically built plugins in a Windows DAW.

[Markus Seeber]

Post by Markus Seeber

Post by nils
Bottom line: It turned out the Windows way of shipping all or most
libs with the program is a really good way to compatibility.

Just employ static linking when sensible.
...
The current way of bundling shared libraries with the application ist just a dirty workaround
for Problems that combines the worst parts of static and dynamic linking,
introduces bloat and solves problems that are mostly caused by employing dynamic
linking in the first place.

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-dynamic-linking-for-the-windows-runtime-by-default/25276
Basically, with the latest updates, you can only load a maximum of 64 statically built plugins in a Windows DAW.

But this only concerns the windows runtime library, right? Everything else can still be linked statically.

[Paul Davis]

On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber <

Post by Markus Seeber
​
Just employ static linking when sensible.

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

[Markus Seeber]

Post by Paul Davis
On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber <

Post by Markus Seeber
​
Just employ static linking when sensible.

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

That is exactly the problem with plugins. At the same time I'd say:
"Don't use these GUI librarys for plugins and do not load any plugin that exports these symbols."
and be done with it, let offensive software die. In my eyes writing a plugin GUI
in GTK/Qt is very bad practice for exactly these reasons.

Or even better: Do not run the plugin GUI inside the DAW procces. Surely this comes with
it's own challenges as plugin developers now have to develop IPC mechanisms inside their
plugins and a way to negotiate how the GUI process connects to the plugin DSP part etc... .

Or go the JACK way, but for a DAW we already know that this has it's own problems.

[Gordonjcp]

Post by Markus Seeber

Post by Paul Davis
On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber <

Post by Markus Seeber
​
Just employ static linking when sensible.

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

"Don't use these GUI librarys for plugins and do not load any plugin that exports these symbols."
and be done with it, let offensive software die. In my eyes writing a plugin GUI
in GTK/Qt is very bad practice for exactly these reasons.

So what would you write it in instead?

[Markus Seeber]

Post by Gordonjcp

Post by Markus Seeber

Post by Paul Davis
On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber <

Post by Markus Seeber
​
Just employ static linking when sensible.

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

"Don't use these GUI librarys for plugins and do not load any plugin that exports these symbols."
and be done with it, let offensive software die. In my eyes writing a plugin GUI
in GTK/Qt is very bad practice for exactly these reasons.

So what would you write it in instead?

You can still statically link for example with FLTK and derivatives or roll your
own. On Windows I think Steinberg even provides a GUI toolkit for VST plugins if
I remember correctly? Or go plain ImGui or plain OpenGL or whatever suits?

Maybe robin can give better recommendations since he seems to have done some work
on lv2 GUIs. (maybe see https://github.com/x42/robtk )

[Paul Davis]

On Sun, Dec 10, 2017 at 3:26 PM, Markus Seeber <

​You can still statically link for example with FLTK

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

and derivatives or roll your
own. On Windows I think Steinberg even provides a GUI toolkit for VST plugins if

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

I remember correctly? Or go plain ImGui or plain OpenGL or whatever suits?
Maybe robin can give better recommendations since he seems to have done some work
on lv2 GUIs. (maybe see https://github.com/x42/robtk )

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


​

[Markus Seeber]

Post by Paul Davis
On Sun, Dec 10, 2017 at 3:26 PM, Markus Seeber <

​You can still statically link for example with FLTK

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

and derivatives or roll your
own. On Windows I think Steinberg even provides a GUI toolkit for VST plugins if

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

I remember correctly? Or go plain ImGui or plain OpenGL or whatever suits?
Maybe robin can give better recommendations since he seems to have done some work
on lv2 GUIs. (maybe see https://github.com/x42/robtk )

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

Hm, I did not think about that hard enough, honestly. Then again this makes
me want to explore the idea of a plugin GUIs separately from the DAW process.
This is not a new idea, but has it already been implemented and explored in detail,
apart from the obvious translation of MIDI/OSC from/to track automation?

[Filipe Coelho]

Post by Markus Seeber
Hm, I did not think about that hard enough, honestly. Then again this makes
me want to explore the idea of a plugin GUIs separately from the DAW process.
This is not a new idea, but has it already been implemented and explored in detail,
apart from the obvious translation of MIDI/OSC from/to track automation?

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.

[Hanspeter Portner]

Post by Filipe Coelho

Post by Markus Seeber
Hm, I did not think about that hard enough, honestly. Then again this makes
me want to explore the idea of a plugin GUIs separately from the DAW process.
This is not a new idea, but has it already been implemented and explored in detail,
apart from the obvious translation of MIDI/OSC from/to track automation>

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.

There's more info about these issues on the LV2 mailing list archive. Here two
well-suited thread entry points interested individuals may want to look at. The
solutions (aka best practices) are known, they *just* need to be implemented.

[1] http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2016-March/001593.html
[2] http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2017-March/001755.html

[Gordonjcp]

Post by Markus Seeber

Post by Gordonjcp

Post by Markus Seeber
and be done with it, let offensive software die. In my eyes writing a plugin GUI
in GTK/Qt is very bad practice for exactly these reasons.

So what would you write it in instead?

You can still statically link for example with FLTK and derivatives or roll your

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.

[Filipe Coelho]

Post by Gordonjcp

Post by Markus Seeber

Post by Gordonjcp

Post by Markus Seeber
and be done with it, let offensive software die. In my eyes writing a plugin GUI
in GTK/Qt is very bad practice for exactly these reasons.

So what would you write it in instead?

You can still statically link for example with FLTK and derivatives or roll your

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.

I guess I need to cut my hands then. And a bunch of other developers
will too.

Static linking is sometimes the only choice if you want to ensure the
plugin binaries that yourself distribute will work for everyone.
Try using a new fftw3 and then use the binary on a slightly older
system, and you'll see missing symbols.

We had this kind of discussion several times already...

Either we use self-contained plugins, or stop using (shared library
based) plugins altogether.

[Robin Gareus]

Post by Gordonjcp
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.

Keep in mind that audio plugins are not unix.

[Andrew Kelley]

Post by Markus Seeber

Post by Markus Seeber

Post by Gordonjcp

Post by Markus Seeber
and be done with it, let offensive software die. In my eyes writing a

plugin GUI

Post by Markus Seeber

Post by Gordonjcp

Post by Markus Seeber
in GTK/Qt is very bad practice for exactly these reasons.

So what would you write it in instead?

You can still statically link for example with FLTK and derivatives or

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

I am not caught up on the entire conversation, but static linking is great.
Dynamic linking prevents optimizations across library boundaries, and does
work at runtime that could have been done at compile-time. Dynamic linking
makes distribution of binaries more cumbersome and error-prone. There's a
whole product / open source community around this containers concept which
is basically a way to turn a bunch of messy dynamically linked components
into a single static component.

Perhaps you are using hyperbole, but generalization of "statically linking
*anything*" belies a lack of understanding. Should every function of every
object file be dynamically linked? Should we never have an inline function?

There's a time and a place for dynamic linking, and it's plugins. But even
so, you want each plugin to be statically linked, and the only thing
dynamic is that you can load the plugin code from the host application at
runtime.

Regards,
Andrew Kelley
http://ziglang.org/

Post by Markus Seeber
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
_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[Len Ovens]

Post by Markus Seeber

Post by nils
Bottom line: It turned out the Windows way of shipping all or most
libs with the program is a really good way to compatibility.

Just employ static linking when sensible. There are less ways a linker can screw that up

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

[Gordonjcp]

Post by Louigi Verona
This is a good point, Fons.
On Windows it is typical to bundle a program with stable libraries and
dependencies. Is this strategy thinkable on FLOSS systems?

No, and it's a stupid idea on Windows too, which is why Windows uniquely
suffers from "DLL Hell".

Just write your software so it doesn't break APIs.

[Will J Godfrey]

On Sat, 9 Dec 2017 13:37:30 +0000

Post by Gordonjcp

Post by Louigi Verona
This is a good point, Fons.
On Windows it is typical to bundle a program with stable libraries and
dependencies. Is this strategy thinkable on FLOSS systems?

No, and it's a stupid idea on Windows too, which is why Windows uniquely
suffers from "DLL Hell".
Just write your software so it doesn't break APIs.

I rather thought it was library API changes that were breaking the software -
something I've been a victim of.

[Neil C Smith]

Post by Gordonjcp

Post by Louigi Verona
This is a good point, Fons.
On Windows it is typical to bundle a program with stable libraries and
dependencies. Is this strategy thinkable on FLOSS systems?

No, and it's a stupid idea on Windows too, which is why Windows uniquely
suffers from "DLL Hell".

Er, yes it's thinkable, and you do realise what's being talked about is
quite distinctly different from, in fact opposite to, DLL Hell?

Sometimes I miss my old RiscOS days and their self contained application
bundles!

Best wishes,

Neil

Post by Gordonjcp
--

Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

[Paul Davis]

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.

Post by Gordonjcp

Post by Louigi Verona
This is a good point, Fons.
On Windows it is typical to bundle a program with stable libraries and
dependencies. Is this strategy thinkable on FLOSS systems?

No, and it's a stupid idea on Windows too, which is why Windows uniquely
suffers from "DLL Hell".
Just write your software so it doesn't break APIs.
--
Gordonjcp
_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[Jeremy Jongepier]

Post by Louigi Verona
This is a good point, Fons.
On Windows it is typical to bundle a program with stable libraries and
dependencies. Is this strategy thinkable on FLOSS systems?

Yes, think of packaging solutions like Snappy (https://snapcraft.io/),
Flatpak (https://flatpak.org/) or AppImage (https://appimage.org/).

Jeremy

[Ralf Mardorf]

Post by Fons Adriaensen

for instance, when preparing for the sonoj convention, i had carla
start crashing on me and i could not complete music examples. i
eventually had to revert to flstudio to make them.

Interesting that you mention carla. I wanted to give it a try some
months ago.

Regarding pacman.conf I planed to do the same back in 2015.

Post by Fons Adriaensen
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.

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

[***@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)
[***@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 <***@rocketmail.com>
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

[***@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]

[Paul Davis]

Post by Fons Adriaensen
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.

​As a plugin host, Carla attempts (and generally does) allow plugins to use
many different toolkits for their own GUIs. To do that, it has to have
small amounts of "stub" code that connect it to each possible toolkit.

This list of dependencies mostly just reflects that, rather than anything
to do with Carla's own implementation.​
​

[Ralf Mardorf]

​As a plugin host, Carla attempts (and generally does) allow plugins
to use many different toolkits for their own GUIs.

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.

[Hermann Meyer]

Post by Ralf Mardorf

​As a plugin host, Carla attempts (and generally does) allow plugins
to use many different toolkits for their own GUIs.

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.

As already mentioned, this are all optional dependency's. Even the samplers.
Think about yourself, for what should a audio plugin host use samplers??

Post by Ralf Mardorf
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 is fully understandable, but, should this lead a developer to
disable features by default?
Even then, distro maintainer usually trying to enable as much features
as possible, even when they been disabled by default.

[Paul Davis]

Post by Ralf Mardorf

Post by Paul Davis
​As a plugin host, Carla attempts (and generally does) allow plugins
to use many different toolkits for their own GUIs.

Do you think that Fons is an idiot, not being aware of this?

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

[Luddy Harrison]

Did you rule out the obvious explanation, i.e., that this Mac had a
previous owner, and the previous owner invoked Find My Mac at some point?

As to a culprit, I would look to the reseller from whom you bought this
machine and not Apple itself. Was Apple even involved directly in this
transaction, other than the original sale of the new MBP to its first owner?

-Luddy Harrison

Send Linux-audio-dev mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.linuxaudio.org/listinfo/linux-audio-dev
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Linux-audio-dev digest..."
1. Forgive me, for I have sinned, or: toss your Macintosh, as
fast and wide as you can. (J?rn Nettingsmeier)
2. Re: Forgive me, for I have sinned, or: toss your Macintosh,
as fast and wide as you can. (David Runge)
3. Re: Forgive me, for I have sinned, or: toss your Macintosh,
as fast and wide as you can. (Albert Graef)
4. Re: Forgive me, for I have sinned, or: toss your Macintosh,
as fast and wide as you can. (Louigi Verona)
----------------------------------------------------------------------
Message: 1
Date: Mon, 4 Dec 2017 10:37:19 +0100
To: The Linux Audio Developers' Mailing List
Subject: [LAD] Forgive me, for I have sinned, or: toss your Macintosh,
as fast and wide as you can.
Content-Type: text/plain; charset=utf-8; format=flowed
Here's me, having to deal with a 48 channel live recording over the
course of six shows. Since my MADI gear is kinda heavy and the rental
company had a Dante system on offer, I dusted off the 2013 Macbook pro I
bought used, purchased a Dante virtual soundcard license from Audinate
and happily tracked the first three shows with Ardour.
On the train on an off-day, I started a rough mix-down so that the
client can begin the selection process. In the middle of exporting, my
Mac shuts down and boots into a PIN unlock screen, telling me it has
been locked via "Find-my-Mac".
For the record, this Macbook had been purchased from a reputable large
online dealer, and it had been factory-reset and completely installed
from scratch.
The first thing I find as I frantically research this issue (on my
proper laptop, that is controlled by me, not by some iFuckwits), is that
this iFeature even contains the option of a remote data wipe.
My excuses to my fellow passengers who got in the way of a stream of
expletives suddenly bursting forth from an otherwise unobtrusive
business traveller, as said traveller notices he doesn't have a
screwdriver to yank his data drive out of this ransomware machine, and
cannot even be sure it's off when it says it's off because of course the
battery cannot be removed without major surgery, either.
Was able to salvage the data at home using a real operating system on
real hardware, and today I'm going to find an authorized mac reseller
and give the guy at the guru bar a day he will remember and testify
about at the next Apple employee incentive day.
Long story short: don't.
--
J?rn Nettingsmeier
De Rijpgracht 8, 1055VR Amsterdam, Nederland
<https://maps.google.com/?q=De+Rijpgracht+8,+1055VR+Amsterdam,+Nederland&entry=gmail&source=g>
Tel. [phone] <+49%20177%207937487>
Meister f?r Veranstaltungstechnik (B?hne/Studio), Tonmeister VDT
http://stackingdwarves.net
------------------------------
Message: 2
Date: Mon, 4 Dec 2017 11:27:29 +0100
Cc: The Linux Audio Developers' Mailing List
Subject: Re: [LAD] Forgive me, for I have sinned, or: toss your
Macintosh, as fast and wide as you can.
Content-Type: text/plain; charset="utf-8"

Post by Jörn Nettingsmeier
Long story short: don't.

Holy...
Glad you got your data at least. This would also freak me out a lot...
--
https://sleepmap.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <
http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20171204/df220008/attachment-0001.pgp
------------------------------
Message: 3
Date: Mon, 4 Dec 2017 11:40:16 +0100
Cc: The Linux Audio Developers' Mailing List
Subject: Re: [LAD] Forgive me, for I have sinned, or: toss your
Macintosh, as fast and wide as you can.
<CA+rUic1g8cbXEhMHAOENqnm+u5At=rfc3=
Content-Type: text/plain; charset="utf-8"
On Mon, Dec 4, 2017 at 10:37 AM, J?rn Nettingsmeier <

Post by Jörn Nettingsmeier
Long story short: don't.

Holy cow.
I like funny war stories like these. Of course it's only funny if you're
not bitten yourself. :( I feel with you.
At least you got a 2013 MB which is still half-decent hardware compared to
the fancy shiny thingies they sell for premium prices these days. Where you
can gain root without a password and need a USB-C dongle of substantial
size to connect to just about *any* kind of useful, non-snowflake
peripheral. Well, at least it connects to your power supply, isn't that
great? :)
Take care,
Albert
--
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
WWW: https://plus.google.com/+AlbertGraef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20171204/d3f3cfdf/attachment-0001.html
------------------------------
Message: 4
Date: Mon, 4 Dec 2017 11:52:30 +0100
Cc: The Linux Audio Developers' Mailing List
Subject: Re: [LAD] Forgive me, for I have sinned, or: toss your
Macintosh, as fast and wide as you can.
<
Content-Type: text/plain; charset="utf-8"
You realize, of course, that this is probably a bug and that this was not
intended by Apple? You should also understand that millions of people are
using Macs everyday and their data doesn't get lost, right?
Because, if not, I can supply many-many stories where I would loose data
because of stupid Linux machines, lose gigs because suddenly the music
software wouldn't start, although it did just yesterday. There are enough
problems that stem from software not having an owner that from it "being
controlled" by someone else. And then after bashing Linux, I can finish my
email with a dramatic "don't".
Any system can fail, and it is never at the right time. And in my
experience, proprietary systems are generally much more stable than floss,
and are less likely to fail suddenly and without warning.
For instance, when preparing for the Sonoj convention, I had Carla start
crashing on me and I could not complete music examples. I eventually had to
revert to FLStudio to make them.
At the Sonoj Convention, 10 minutes before my dj set, Mixxx has deleted all
of my tracks library and I had to frantically search for a fix. I found a
workaround, but could not include a couple of new tunes into the set.
Did I write a post blaming floss for that? No.

Post by Jörn Nettingsmeier
On Mon, Dec 4, 2017 at 10:37 AM, J?rn Nettingsmeier <

Post by Jörn Nettingsmeier
Long story short: don't.

Holy cow.
I like funny war stories like these. Of course it's only funny if you're
not bitten yourself. :( I feel with you.
At least you got a 2013 MB which is still half-decent hardware compared

to

Post by Jörn Nettingsmeier
the fancy shiny thingies they sell for premium prices these days. Where

you

Post by Jörn Nettingsmeier
can gain root without a password and need a USB-C dongle of substantial
size to connect to just about *any* kind of useful, non-snowflake
peripheral. Well, at least it connects to your power supply, isn't that
great? :)
Take care,
Albert
--
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
WWW: https://plus.google.com/+AlbertGraef
_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev

--
Louigi Verona
https://www.patreon.com/droning
https://louigiverona.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20171204/f2051328/attachment-0001.html
------------------------------
Subject: Digest Footer
_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev
------------------------------
End of Linux-audio-dev Digest, Vol 130, Issue 1
***********************************************

[Thomas Brand]

Post by Jörn Nettingsmeier
On the train on an off-day, I started a rough mix-down so that the
client can begin the selection process. In the middle of exporting, my Mac
shuts down and boots into a PIN unlock screen, telling me it has been
locked via "Find-my-Mac".

Scary that this can happen out of the blue .. !
Another issue is that most standard gear has the IME which if vulnerable
is the door to more such fun.
Thanks for sharing the experience,

[Kjetil Matheussen]

Post by nils
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.

Definitely. Including as many 3rd party dependencies as possible makes life
easier both for software providers and users.
The biggest advantage is that you avoid all the bugs caused by incompatible
(or too old) versions of libraries people might have on their system.