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

[Andrew Kelley]

On Tue, Dec 12, 2017 at 10:02 AM, Gordonjcp  wrote:

> On Sun, Dec 10, 2017 at 09:26:55PM +0100, Markus Seeber wrote:
> > >> 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 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/


>
> 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
> Linux-audio-dev@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Robin Gareus]

On 12/12/2017 04:02 PM, Gordonjcp 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.

Keep in mind that audio plugins are not unix.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Filipe Coelho]

On 12.12.2017 16:02, Gordonjcp wrote:

On Sun, Dec 10, 2017 at 09:26:55PM +0100, Markus Seeber wrote:

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.


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

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

[Gordonjcp]

On Sun, Dec 10, 2017 at 09:26:55PM +0100, Markus Seeber wrote:
> >> 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.

-- 
Gordonjcp

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

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

[Hanspeter Portner]

On 10.12.2017 22:19, Filipe Coelho wrote:
> On 10.12.2017 22:14, Markus Seeber wrote:
>> 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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Filipe Coelho]

On 10.12.2017 22:14, Markus Seeber wrote:

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.


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

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

[Markus Seeber]

On 12/10/2017 09:37 PM, Paul Davis wrote:
> On Sun, Dec 10, 2017 at 3:26 PM, Markus Seeber <
> markus.see...@spectralbird.de> wrote:
>
>> ​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?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Paul Davis]

On Sun, Dec 10, 2017 at 3:26 PM, Markus Seeber <
markus.see...@spectralbird.de> wrote:

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


​
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Markus Seeber]

On 12/10/2017 08:43 PM, Gordonjcp wrote:
> On Sun, Dec 10, 2017 at 08:37:08PM +0100, Markus Seeber wrote:
>> On 12/10/2017 03:31 PM, Paul Davis wrote:
>>> On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber <
>>> markus.see...@spectralbird.de> wrote:
>>>
 ​
 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.
> 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 )

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

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

[Gordonjcp]

On Sun, Dec 10, 2017 at 08:37:08PM +0100, Markus Seeber wrote:
> On 12/10/2017 03:31 PM, Paul Davis wrote:
> > On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber <
> > markus.see...@spectralbird.de> wrote:
> >
> >> ​
> >> 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.

So what would you write it in instead?

-- 
Gordonjcp

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

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

[Markus Seeber]

On 12/10/2017 03:31 PM, Paul Davis wrote:
> On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber <
> markus.see...@spectralbird.de> wrote:
>
>> ​
>> 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.

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

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

[Len Ovens]

On Sun, 10 Dec 2017, Markus Seeber wrote:


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

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

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

[Paul Davis]

On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber <
markus.see...@spectralbird.de> wrote:

> ​
> 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.​
​
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Markus Seeber]

On 12/10/2017 12:14 PM, Filipe Coelho wrote:
> On 10.12.2017 11:51, Markus Seeber wrote:
>> On 12/09/2017 02:32 PM, nils wrote:
>>> 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.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Filipe Coelho]

On 10.12.2017 11:51, Markus Seeber wrote:

On 12/09/2017 02:32 PM, nils wrote:

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.


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

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

[Kjetil Matheussen]

>
> From: 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.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Markus Seeber]

On 12/09/2017 02:32 PM, nils wrote:
> 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.
>
> 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.

>
> On 12/09/2017 02:24 PM, Louigi Verona wrote:
>> 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
>> Linux-audio-dev@lists.linuxaudio.org
>> https://lists.linuxaudio.org/listinfo/linux-audio-dev
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

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

[Paul Davis]

> Am 09.12.2017 um 23:59 schrieb Ralf Mardorf:
>
>> On Sat, 9 Dec 2017 09:44:02 -0500, Paul Davis wrote:
>>
>>> ​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.
​
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Hermann Meyer]

Am 09.12.2017 um 23:59 schrieb Ralf Mardorf:

On Sat, 9 Dec 2017 09:44:02 -0500, Paul Davis wrote:

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


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.




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

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

[Ralf Mardorf]

On Sat, 9 Dec 2017 09:44:02 -0500, Paul Davis wrote:
>​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.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Jeremy Jongepier]

On 12/09/2017 02:24 PM, Louigi Verona wrote:
> 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



signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

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


On Sat, Dec 9, 2017 at 8:37 AM, Gordonjcp  wrote:

> On Sat, Dec 09, 2017 at 02:24:37PM +0100, Louigi Verona wrote:
> > 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
> Linux-audio-dev@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Paul Davis]

On Sat, Dec 9, 2017 at 6:36 AM, Fons Adriaensen  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.
> .
>
> 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.​
​
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Neil C Smith]

On Sat, 9 Dec 2017, 13:37 Gordonjcp,  wrote:

> On Sat, Dec 09, 2017 at 02:24:37PM +0100, Louigi Verona wrote:
> > 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

> --
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Will J Godfrey]

On Sat, 9 Dec 2017 13:37:30 +
Gordonjcp  wrote:

>On Sat, Dec 09, 2017 at 02:24:37PM +0100, Louigi Verona wrote:
>> 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.

-- 
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.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Gordonjcp]

On Sat, Dec 09, 2017 at 02:24:37PM +0100, Louigi Verona wrote:
> 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
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

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

On 12/09/2017 02:24 PM, Louigi Verona wrote:
> 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
> Linux-audio-dev@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

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

[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
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Fons Adriaensen]

On Mon, Dec 04, 2017 at 11:52:30AM +0100, Louigi Verona wrote:
 
> 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.
.

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)

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

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

[Ralf Mardorf]

On Tue, 5 Dec 2017 17:21:05 +0100, Louigi Verona wrote:
>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.

>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.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[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!

















On Tue, Dec 5, 2017 at 6:30 PM, Paul Davis 
wrote:

>
>
> On Tue, Dec 5, 2017 at 11:21 AM, Louigi Verona 
> wrote:
>
>> 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
https://www.patreon.com/droning
https://louigiverona.com/
___
Linux-audio-dev mailing list

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

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


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!



--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

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






On Tue, Dec 5, 2017 at 4:13 PM, A. P. Garcia 
wrote:

> On Mon, Dec 4, 2017 at 6:46 AM, Louigi Verona 
> wrote:
> > 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.
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
>



-- 
Louigi Verona
https://www.patreon.com/droning
https://louigiverona.com/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[A. P. Garcia]

On Mon, Dec 4, 2017 at 6:46 AM, Louigi Verona  wrote:
> 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.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[A. P. Garcia]

On Mon, Dec 4, 2017 at 6:09 AM, Neil C Smith
 wrote:
>
>
> On Mon, Dec 4, 2017 at 10:52 AM Louigi Verona 
> wrote:
>>
>> 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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Thomas Brand]

On Mon, December 4, 2017 10:37, Jörn Nettingsmeier wrote:
> 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,

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

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

[Robin Gareus]

On 12/04/2017 06:52 PM, Jörn Nettingsmeier wrote:
> On 12/04/2017 01:30 PM, Robin Gareus wrote:
> 
>> 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 ;-))
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Len Ovens]

On Mon, 4 Dec 2017, Neil C Smith wrote:


On Mon, Dec 4, 2017 at 10:52 AM Louigi Verona  wrote:
  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

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

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

[Kevin Cole]

On Mon, Dec 4, 2017 at 10:52 AM Louigi Verona 
wrote:

> 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, ;-)
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Kevin Cole]

On Mon, Dec 4, 2017 at 7:09 AM, Louigi Verona  wrote:

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

-- 
Kevin Cole, RHCE
Team Contact
Ubuntu Linux DC "LoCo"
Washington, DC (US)
GPG Key ID:0x3E696927
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[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

On Mon, Dec 4, 2017 at 4:00 AM 
wrote:

> Send Linux-audio-dev mailing list submissions to
> linux-audio-dev@lists.linuxaudio.org
>
> 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
> linux-audio-dev-requ...@lists.linuxaudio.org
>
> You can reach the person managing the list at
> linux-audio-dev-ow...@lists.linuxaudio.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linux-audio-dev digest..."
>
>
> Today's Topics:
>
>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
> From: J?rn Nettingsmeier 
> 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.
> Message-ID: <839b300f-71a8-3d88-e127-b7fc3edc5...@stackingdwarves.net>
> 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
> 
> Tel. +49 177 7937487 <+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
> From: David Runge 
> To: J?rn Nettingsmeier 
> 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.
> Message-ID: <20171204102729.GE16499@dvzrv.localdomain>
> Content-Type: text/plain; charset="utf-8"
>
> On 2017-12-04 10:37:19 (+0100), J?rn Nettingsmeier wrote:
> > 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: <
> 

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

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

On Mon, Dec 4, 2017 at 1:40 PM, Neil C Smith 
wrote:

>
> On Mon, Dec 4, 2017 at 12:31 PM Louigi Verona 
> wrote:
>
>> 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
>



-- 
Louigi Verona
https://www.patreon.com/droning
https://louigiverona.com/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Neil C Smith]

On Mon, Dec 4, 2017 at 12:31 PM Louigi Verona 
wrote:

> 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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[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



signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

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

On Mon, Dec 4, 2017 at 1:28 PM, Neil C Smith 
wrote:

> Hi,
>
> On Mon, Dec 4, 2017 at 12:12 PM Louigi Verona 
> wrote:
>
>> 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
>



-- 
Louigi Verona
https://www.patreon.com/droning
https://louigiverona.com/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Robin Gareus]

On 12/04/2017 11:52 AM, Louigi Verona wrote:
> 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.


> 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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Neil C Smith]

Hi,

On Mon, Dec 4, 2017 at 12:12 PM Louigi Verona 
wrote:

> 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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

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

On Mon, Dec 4, 2017 at 1:09 PM, Neil C Smith 
wrote:

>
>
> On Mon, Dec 4, 2017 at 10:52 AM Louigi Verona 
> wrote:
>
>> 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
>



-- 
Louigi Verona
https://www.patreon.com/droning
https://louigiverona.com/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Neil C Smith]

On Mon, Dec 4, 2017 at 10:52 AM Louigi Verona 
wrote:

> 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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

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



On Mon, Dec 4, 2017 at 1:01 PM, David Runge  wrote:

> On 2017-12-04 11:52:30 (+0100), Louigi Verona wrote:
> > 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.
>
> > 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
>
> --
> https://sleepmap.de
>



-- 
Louigi Verona
https://www.patreon.com/droning
https://louigiverona.com/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[David Runge]

On 2017-12-04 11:52:30 (+0100), Louigi Verona wrote:
> 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.

> 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

-- 
https://sleepmap.de


signature.asc
Description: PGP signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

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






On Mon, Dec 4, 2017 at 11:40 AM, Albert Graef  wrote:

> On Mon, Dec 4, 2017 at 10:37 AM, Jörn Nettingsmeier <
> netti...@stackingdwarves.net> wrote:
>
>> 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
> Email:  aggr...@gmail.com
> WWW:https://plus.google.com/+AlbertGraef
>
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
>
>


-- 
Louigi Verona
https://www.patreon.com/droning
https://louigiverona.com/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Albert Graef]

On Mon, Dec 4, 2017 at 10:37 AM, Jörn Nettingsmeier <
netti...@stackingdwarves.net> wrote:

> 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
Email:  aggr...@gmail.com
WWW:https://plus.google.com/+AlbertGraef
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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



--
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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev