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

Andrew Kelley superjoe30 at gmail.com
Tue Dec 12 16:08:35 UTC 2017


On Tue, Dec 12, 2017 at 10:02 AM, Gordonjcp <gordonjcp at gjcp.net> 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 at lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20171212/224d93b5/attachment.html>


More information about the Linux-audio-dev mailing list