10:43 a.m.
On Thu, 2018-10-04 at 15:26 +0100, Daniel P. Berrangé wrote:
On Thu, Oct 04, 2018 at 04:08:31PM +0200, Andrea Bolognani wrote:
> I think keeping up with changes in libraries you consume is simply
> due diligence for developers, and while of course that takes up
> some of your time and is for the most part hardly a glamorous job,
> it also ensures your application is in tip-top shape at any given
> time and is taking advantage of all possible improvements in the
> underlying tech by periodically reconsidering parts of its design,
> which will ultimately result in a better experience for users.
Changing existing code to use new APIs doesn't imply the app
is in tip-top shape. On the contrary, I can arguably make it
more likely to break in subtle ways by changing something which
is long tested in the field for something new & relatively
untested.
You don't have to be an early adopter: it's perfectly fine to wait
a few point releases before moving to a new API. Never addressing
the deprecation warnings, though, is hardly going to result in
better code in the long run.
> And libvirt developers themselves not having to tiptoe around
what
> is in some cases quite literally a decade worth of backwards
> compatibility hacks would allow them to focus on features and bug
> fixes that actually impact users in a positive way, all the while
> keeping the size of the library from growing out of control, with
> all the resource usage and attack suface consideration that entails.
Maintaining API compatibility is not really the main contributor
to resource usage or attack surface. That is a large architectural
issue, such as the monolithic libvirtd and usage memory unsafe
language for impl. Deprecating & removing features or changing
defaults will have negligible impact.
It is certainly forcing us to write more complex logic, which is
easier to get wrong and will result in more bugs regardless of
how safe the programming language we use is.
Not that I'm opposing any of the changes you mention, mind you :)
> > As a counter point, Microsoft Windows never breaks its APIs
and
> > that has many orders of magnitude more app developers than GTK/Qt
>
> How many of the bugs and crashes experienced daily by Windows users
> could be avoided if applications were forced to adopt newer, safer
> APIs over time instead of being allowed to lazily stick to whatever
> was available at the time Windows 95 was the new hotness?
The idea that you can force people to adapt is flawed. Some devs
may adapt. Others simply won't so an app that otherwise worked
fine will now be needlessly broken. Others will simply bundle
the older version of your API in their code getting stuck on
old outdated insecure versions.
Are those the kind of applications you'd trust to manage your
virtualization cluster?
If the developers can't be bothered to put out a new release
for literally *years*, then you're better off using pretty much
anything else.
> Your guess is as good as mine, but I'm pretty sure the
answer is
> not "zero".
Adapting to new APIs will itself introduce new bugs. Libvirt has felt
this when we've had to adapt to APIs changing in things we use too.
Adding support for new QEMU features also sometimes results in new
bugs popping up, but that should teach us to write and test our
code more carefully, not to give up on keeping up with the
innovations happening in QEMU.
> > The fact that libvirt never breaks API is one of our
greatest
> > selling points.
>
> I don't have hard data on this, but I suspect the success of
> libvirt is driven more by the great features it offers than its
> promise to preserve API/ABI compatibility forever; even more so
> considering that the majority of Open Source projects don't offer
> anything close to the latter, and yet somehow manage to thrive.
GTK's API breakage means that we still have applications in Fedora
that are stuck on GTK1, despite fact that GTK3 is current and GTK4
is coming soon.
'dnf repoquery --whatrequires gtk+' reports ~30 results, a big chunk
of which are related to XMMS, a media player that's not been updated
in 10+ year; GTK+ 1 itself hasn't seen a release since 2011.
Allowing them to still be just a 'dnf install' away for any user is
borderline irresponsible IMHO.
The world of hurt caused by Python's gratuituous
incompatbilities between py2 and py3 is going to continue to harm
the python community for years to come.
For what it's worth, and that's probably not much, according to the
TIOBE Index Python is more popular now that it's ever been, and it
has climbed back from 5th to 3rd place over the past year, despite
it being arguably one of the worst times for Python programmers who
had been putting off the 2->3 transition until the very last moment.
--
Andrea Bolognani / Red Hat / Virtualization