1742: "Will It Work"

This forum is for the individual discussion thread that goes with each new comic.

Moderators: Moderators General, Prelates, Magistrates

rmsgrey
Posts: 3655
Joined: Wed Nov 16, 2011 6:35 pm UTC

Re: 1742: "Will It Work"

Postby rmsgrey » Sat Oct 08, 2016 1:25 pm UTC

Yeah, one of the underlying assumptions of the open source model is expressed by "with enough eyes, all bugs are shallow" - or, to put it another way, for any problem the software develops, there's already someone out there who can solve it easily.

The problem then is not finding someone willing to put in the work to fix it, but rather finding someone for whom fixing it isn't work.

User avatar
Copper Bezel
Posts: 2426
Joined: Wed Oct 12, 2011 6:35 am UTC
Location: Web exclusive!

Re: 1742: "Will It Work"

Postby Copper Bezel » Sat Oct 08, 2016 5:52 pm UTC

It's a nice idea. But a lot of open source code is written for a paycheck, too, and in projects where that's not the case, there are often a few, or a single, top maintainer and developer doing the bulk of the work.

We absolutely need open source, as much as we need proprietary development, but it's not a utopia that solves the problem of labor cost by magic.

ps.02 wrote:
Copper Bezel wrote:When two apps are written against different versions of the same library, which is where the repo model simply breaks and does not work,

That is an interesting assertion that depends a great deal on how poorly the repository and its software are designed and maintained, say, on a scale of Debian to rpmfind.net circa 1998.

So, I mean, if your experience with software repositories is more on the rpmfind.net-in-1998 end of the scale, I can see why you'd think that. But as I'm sure xtifr remembers*, Debian migrated libc, its most core library, the one every package on the entire system (except the Linux kernel itself) depends on directly or indirectly, between three mutually incompatible versions, without breaking running systems. You could have libc4 and libc5 and libc6 all on one system, each used by whichever apps were built for them. Including whole chains of libraries.

Migrating the entire Debian system between libc versions took quite awhile (partly because there was no real urgency, as everything continued to work) - but I can recall no point when any applications were broken or uninstallable on account of the transitions.

*This was in 1996. I think he was around.

Yet my Ubuntu system still gives me "depends on *lib* but *lib* is not going to be installed" sorts of errors in real life in the 2010s. The fundamental point is that dependency hell is something you can solve by degrees, while the app store model solves it and downloads extra junk in those cases where the repo model fails. Claiming that the repo model is more "convenient" or user-oriented is simply wrong and at least a little disingenuous.
So much depends upon a red wheel barrow (>= XXII) but it is not going to be installed.

she / her / her

ps.02
Posts: 378
Joined: Fri Apr 05, 2013 8:02 pm UTC

Re: 1742: "Will It Work"

Postby ps.02 » Sat Oct 08, 2016 7:16 pm UTC

Copper Bezel wrote:
ps.02 wrote:
Copper Bezel wrote:When two apps are written against different versions of the same library, which is where the repo model simply breaks and does not work,

That is an interesting assertion that depends a great deal on how poorly the repository and its software are designed and maintained, say, on a scale of Debian to rpmfind.net circa 1998.

Yet my Ubuntu system still gives me "depends on *lib* but *lib* is not going to be installed" sorts of errors in real life in the 2010s. The fundamental point is that dependency hell is something you can solve by degrees, while the app store model solves it and downloads extra junk in those cases where the repo model fails.

Ah, I see. I thought your original statement implied that the repository model simply cannot accommodate multiple versions of a library at all. That's what I set out to debunk. Debian has been shipping multiple coinstallable versions of libraries for 20 years, and Red Hat I think even longer, via a slightly different mechanism.

What I would agree with is that the repository model requires that library authors/maintainers follow some best practices, some of which are poorly understood, in order to avoid these messes. If they do, app maintainers are pretty free to use whatever versions of libraries they want or need, and things run pretty smoothly. But if they do not, the system is not very forgiving.

User avatar
Sableagle
Ormurinn's Alt
Posts: 2152
Joined: Sat Jun 13, 2015 4:26 pm UTC
Location: The wrong side of the mirror
Contact:

Re: 1742: "Will It Work"

Postby Sableagle » Sat Oct 08, 2016 10:58 pm UTC

Personal experience of things to add to this scale:

Somewhere near the app store: Steam games ... eventually.
Somewhere near Sourceforge: mods for Steam games.
Somewhere near Geocities: Bethesda games.
Somewhere near Unlikely: Steam games, the first time you download them.
Somewhere near the carpet (assuming you're viewing this image on a desktop monitor): simultaneous multiple mods for Bethesda games.
Zohar wrote:You don't know what you're talking about. Please spare me your quote sniping and general obliviousness.

CorruptUser wrote:Just admit that you were wrong ... and your entire life, cyberspace and meatspace both, would be orders of magnitude more enjoyable for you and others around you.

xtifr
Posts: 366
Joined: Wed Oct 01, 2008 6:38 pm UTC

Re: 1742: "Will It Work"

Postby xtifr » Sun Oct 09, 2016 2:10 am UTC

Copper Bezel wrote:Yeah, no. There's no massive duplication of libraries if they're linked off anyway and only downloaded new when they're needed.

But how is the system supposed to identify "new"? If I see there's an update to App1, and it includes a new version of shared library SL1, that's great, but then if I update App2, and it includes the old version of the library, then isn't the system going to "update" me back to that old version? And what if the guy who packages App3 has built a custom version of SL1 with features he doesn't use compiled out? Will updating App3 end up breaking everything else which uses those features of SL1? And all of this depends on the not-entirely-reliable technology of creating replicable builds. Which in turn, depends on the builders of each app using those features, which aren't always easy to use. A lot of them won't bother, and then I'll get updates to SL1 with each app.

When two apps are written against different versions of the same library, which is where the repo model simply breaks and does not work, you have a slightly bigger download. Dear me, what shall we do.

Um, when you need different versions, the repo model gives you annoying error messages about conflicts (if the repo maintainers took an overly naive approach to packaging the library), while the app-store model causes random programs to break on your system! (Because at least one of them is going to be running with an incompatible library.) I think that's a much bigger problem than anything the repo model throws at you!

Of course, the store model can put the different versions of the library in different places. But so can the repo model! And the big difference there is that the people creating the repo know what's in the repo, while the people packaging individual apps will frequently have no awareness of each other, and are much more likely to step on each others' feet and accidentally break each other's apps.

As ps.02 mentioned, the libc->glibc transition (which affected everything) absolutely proved that the repo model can handle arbitrarily complex situations of the type you're claiming it can't handle at all. The fact that some people don't use the tool as effectively as they ought doesn't mean that it's a less useful tool than the outright dangerously-broken-by-design app store model.

Of course, the store model can easily be fixed--by replacing it with the repo model, but hiding the details from the users, so they only see the apps. But guess what? That's not evidence that the store model is better than the repo model! :mrgreen:

(It can also be fixed with the android model, where each app gets a sandboxed arena of its own, but then we're back to downloading the same library hundreds of times, once for each sandbox.)
"[T]he author has followed the usual practice of contemporary books on graph theory, namely to use words that are similar but not identical to the terms used in other books on graph theory."
-- Donald Knuth, The Art of Computer Programming, Vol I, 3rd ed.

User avatar
Copper Bezel
Posts: 2426
Joined: Wed Oct 12, 2011 6:35 am UTC
Location: Web exclusive!

Re: 1742: "Will It Work"

Postby Copper Bezel » Sun Oct 09, 2016 3:41 am UTC

xtifr wrote:Um, when you need different versions, the repo model gives you annoying error messages about conflicts (if the repo maintainers took an overly naive approach to packaging the library), while the app-store model causes random programs to break on your system! (Because at least one of them is going to be running with an incompatible library.) I think that's a much bigger problem than anything the repo model throws at you!

There isn't any model that works like that.

No, you start from the purely sandboxed idea, have the massive duplication, and then symlink it away by letting the system know what's contained, in what version, in a given package. Some packages will sometimes cause duplication, instead of failing to install.
So much depends upon a red wheel barrow (>= XXII) but it is not going to be installed.

she / her / her

ps.02
Posts: 378
Joined: Fri Apr 05, 2013 8:02 pm UTC

Re: 1742: "Will It Work"

Postby ps.02 » Sun Oct 09, 2016 9:42 pm UTC

Copper Bezel wrote:No, you start from the purely sandboxed idea, have the massive duplication, and then symlink it away by letting the system know what's contained, in what version, in a given package. Some packages will sometimes cause duplication, instead of failing to install.

Fair points, but installation success doesn't by itself mean much. What really matters is whether, once installed, the software has an environment that upholds the assumptions its maintainers are counting on (compatible libraries, compatible runtime features and ancillary services). Part of this is that installing, upgrading, or removing something shouldn't invalidate the assumptions of other software is already present. It's easy to architect a system by which you can run an installation process and it works reliably and you have an icon on the desktop. That by itself doesn't mean you have a robust system.

(For example, some years ago I heard that the Gentoo Linux package system completely ignored the dependency graph when you removed a package from your system. If removing the package broke something else, the system was not set up to notice, much less try to stop you. Presumably that has since been fixed. But to me that's a pretty gaping robustness hole that is not really accounted for if all you ask is "will random stuff install".)

Now maybe you're taking all this into account when you talk about "failing to install" and its inverse. But that verbiage is ambiguous.

rmsgrey
Posts: 3655
Joined: Wed Nov 16, 2011 6:35 pm UTC

Re: 1742: "Will It Work"

Postby rmsgrey » Sun Oct 09, 2016 11:59 pm UTC

So, basically, the ideal is to use a DEFLATE-style compression on the entire shared-library folder, while preserving pointers into the various files, so that each code fragment is stored once but may be referenced multiple times.

And then do it in a way that's transparent to anything trying to access the shared libraries from outside the folder.

And, of course, you need to distinguish between two libraries with the same exact name, but different binaries (someone, somewhere, will have written something that only works properly because a minor inefficiency in one library prevents thread-lock - and patching that inefficiency to something functionally identical apart from the number of clock-cycles it takes will break it)

And this is how we end up with programs that, in the name of reducing code bloat, install entire "shared" libraries that nothing else uses, just so they can use a routine in another "shared" library when that routine doesn't even depend on the first library in the first place...

User avatar
david.windsor
Posts: 121
Joined: Mon Sep 09, 2013 3:08 pm UTC

Re: 1742: "Will It Work"

Postby david.windsor » Mon Oct 10, 2016 3:44 am UTC

Eebster the Great wrote:This is absolutely ridiculous. Everyone knows the probability of code running successfully depends on the phase of Venus, not the Moon.

yee gads, I feel old, I understand the 'phase of the moon' bug reference.
"All those ... moments, will be lost ... in time, like tears ... in rain."

User avatar
grkvlt
Posts: 26
Joined: Tue Aug 16, 2011 6:42 am UTC
Location: Untied Kingdom
Contact:

Re: 1742: "Will It Work"

Postby grkvlt » Tue Oct 11, 2016 11:21 am UTC

david.windsor wrote:
Eebster the Great wrote:This is absolutely ridiculous. Everyone knows the probability of code running successfully depends on the phase of Venus, not the Moon.

yee gads, I feel old, I understand the 'phase of the moon' bug reference.


The phrase 'depends on the phase of the moon' is in fairly common usage among engineers to describe an unexpected dependency, mostly due to its having been included in the Jargon File, so it's not really anything to make you feel old about. Unless you were thinking of some other referent which I am either not clever enough, or old enough, to get?
distributed systems hacker abstract visitor pattern {{citation-needed}}

reval
Posts: 125
Joined: Fri Sep 23, 2016 2:56 pm UTC

Re: 1742: "Will It Work"

Postby reval » Fri Oct 14, 2016 3:33 pm UTC

grkvlt wrote:The phrase 'depends on the phase of the moon' is in fairly common usage among engineers to describe an unexpected dependency, mostly due to its having been included in the Jargon File


From which one caveat deserves to be quoted:

However, beware of assumptions. A few years ago, engineers of CERN (European Center for Nuclear Research) were baffled by some errors in experiments conducted with the LEP particle accelerator. As the formidable amount of data generated by such devices is heavily processed by computers before being seen by humans, many people suggested the software was somehow sensitive to the phase of the moon. A few desperate engineers discovered the truth; the error turned out to be the result of a tiny change in the geometry of the 27km circumference ring, physically caused by the deformation of the Earth by the passage of the Moon! This story has entered physics folklore as a Newtonian vengeance on particle physics and as an example of the relevance of the simplest and oldest physical laws to the most modern science.


I remember that. They were measuring the mass of the Z boson by measuring how the event cross section changed as they tuned the beam energy. They were able to get quite a few digits of precision (https://en.wikipedia.org/wiki/W_and_Z_bosons says 91.1876±0.0021 GeV/c2), but down at the tail end, the number kept changing as a function of time. Plotting the change, they could see a pattern of daily variation. Not directly the phase of the moon, but dependent on it, because tidal forces depend on the position of the sun and the moon as the Earth rotates. They were seeing tides in the bedrock!


Return to “Individual XKCD Comic Threads”

Who is online

Users browsing this forum: No registered users and 107 guests