Applications and bundled libraries

Posted Mar 17, 2010 23:51 UTC (Wed) by shahms (subscriber, #8877)
In reply to: Applications and bundled libraries by Frej
Parent article: Applications and bundled libraries

Frankly, the centralized control does anything but hurt developers and
users. It might make developers' lives slightly more difficult by requiring
them to actually think about deployment instead of wrapping up their
/usr/lib and pushing it out in one friggin' huge binary, but the end result
is a *better* experience for users as they get regular bug fixes, security
updates and (hopefully) tested upstream changes rather than whatever "fixes"
the application developers thought expedient to cobble together so they
could get the app out the door.

And it's not like the distros are iron-fisted dictators. All of the major
ones do development in the open and are generally welcoming of input,
patches, etc.

to post comments

Applications and bundled libraries

Posted Mar 18, 2010 2:11 UTC (Thu) by drag (guest, #31333) [Link] (6 responses)

Still though packaging should be treated as part of the developer's responsibility and not something that is 'downstream'.

It simply is not realistic to depend on third parties to know the proper way to build everything and know exactly the right combination of dependency versioning and compile flags that you (as a developer) have intended and tested against.

It can work for a few hundred packages easily enough to do it the 'apt-get way'. It can scale upwards to several thousands. But to be on par with something like what Windows provides you have to scale to millions and you have a shitload of programs that nobody in the Debian project (or Fedora or Redhat or anybody else) will never be aware of, much less know enough to package and build them for end users.

There is just simply no chance in hell that a centrally managed, closed system like the current package management status quo can ever hope to scale and meet the diverse needs of the average population.

It has to be a distributed system.. And the only logical way (that I see it) is to do a distributed packaging system is by having it be treated as part of the programming of software and have all packaging happen 'upstream'. "Make install" should not drop binaries onto /usr/local, it should produce a 'deb' or 'rpm' file. Software then should not be distributed through tarballs or central source code repositories, but through built packages.

Distributers would, then, work with upstream package creation and aid and correct problems as they come up and then collect as many popular packages as possible for the convience of the end users.

Distributions cannot behave that they are the sole source of the software and libraries people are going to want and require.

To do that it's going to require substantial changes in how Linux, as a operating system, is managed and coordinated. Centralized repositories are stop-gap at best and only exist through pure brute force of volenteers. It won't continue for ever. People will get burned out doing the same old thing again and again.

The quicker people realize this and be willing to abandon technically excellent solutions for real- world practical/useful ones, the better off all of us are going to be.

Applications and bundled libraries

Posted Mar 18, 2010 3:11 UTC (Thu) by thedevil (guest, #32913) [Link] (1 responses)

No, no, no, no.

I don't consider myself "average". Why should I welcome a product explcitly targeted at "the average population"? I don't care about world domination one bit. Windows can have 99% of the market for all I care. I want something that serves me (a programmer) well. Windows isn't it, and Linux which works just like Windows (hi, Gnome!) wouldn't be it, either.

Besides, you contradict yourself:

"... diverse needs of the average population."

"... the better off *all* of us are going to be."
(emphasis mine)

It can't very well be both.

Applications and bundled libraries

Posted Mar 18, 2010 9:14 UTC (Thu) by dgm (subscriber, #49227) [Link]

OK, so you're a programmer and you're soo special. Fine, so do I. But do you realize that that you run a UNIX like system on cheap PC hardware thanks to the MILLIONS of people that buy the same kind of hardware, don't you?

The same logic applies to software. If we hide in the proverbial Ivory Tower, the OS that so wonderfully works for us will languish and die.

The moral being, be little more humble my friend.

Applications and bundled libraries

Posted Mar 18, 2010 18:47 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

Strongly disagree.

First, developers are interested in developing, let them do that. Let others take over the packaging. lest you loose developers (ouch!).

Second, not all distributions are equal. They do have different aims: There are "enterprise" distributions, who are commited to UI/API/ABI stability at almost any cost; there are "end user distributions" commited to making the ordinary user's life as simple as possible; then there are the "technology showcase" ones, always shipping the latest&greatest; and "source code only" distributions which take pride in shipping (almost) unchanged upstream sources, mostly from the bleeding edge. Asking any developer to ship packages for each of those use cases means driving them to sheer madness.

Third, just shipping some "standard package" doesn't help a bit. Witness what became of LSB, which aimed at providing a common base for shipping binaries. The stuff they standardized on was too minimal and too soon outdated to be of any relevance.

Fourth, in FLOSS we have the option to fix the source, and package that. Most closed source applications are bought once, and users would scream if they had to pay again just because the operating system vendor decided to update some random library. And this works both ways, the applications are forced to aim at a low common denominator (or ship their own environment), while the vendor has to bend over backwards so as to minimize breakage (the story of the Microsoft "fix" for a bug in Simcity is just a case in point). And support the resulting mess for 10 or more years (take Windows XP, which refuses to die to this day, after two successor systems shipped) and even longer (there are "backward compatibility" layers in current Windows systems dating back who knows when).

Lastly, one of the strengths of Linux (and Unixy systems in general) is precisely their diversity. Your comment talks only of Linux distributions, and predicts there will only be one distribution in a short while. Sorry to disappoint you, this has been predicted often during the last 20 or so Linux years, and if anything is farther from reality now than ever before. And then you have to figure in other systems like Solaris, Apple's OSX, the swarm of BSDs, and even stuff like CygWin, not to mention closed and/or obsolescent systems, not to mention the sprouting of embedded systems due to ever growing capacities of "small" systems (my cellphone is way more of a computer than the first machine I programmed ever was...). Think of it as a sort of darwinian breeding ground for software: If it is able to survive in many of those environments, it is probably fit for human consumption. Sure enough, it is also our greatest curse...

Applications and bundled libraries

Posted Mar 21, 2010 18:31 UTC (Sun) by ikm (subscriber, #493) [Link] (1 responses)

> packaging happen 'upstream'. "Make install" should not drop binaries onto /usr/local, it should produce a 'deb' or 'rpm' file. Software then should not be distributed through tarballs or central source code repositories, but through built packages.

Funnily enough, that's exactly what happens under Windows. When you release a piece of software for Windows, all you have to provide is an .exe installer. Why? Because that's what end users expect and because it's quite easy to do (you only have one single platform and packaging format). And everyone's happy! Yes, libraries get bundled, they waste space, have bugs, but this doesn't seem like a major issue for most programs.

In contrast, under Linux you just can't provide 1) debs for three flavors of Debian and two flavors of Ubuntu, 2) rpms for each of the existing RH-derivatives, 3) ebuilds for gentoo and gentoo-derived distros, 4) whatever else other formats are out there. This is just crazy! Thus the only reliable and easy form is to provide compilable source. And let all those zillions of distros do the rest.

So what plagues linux, in my opinion, is that hailed "diversity". It's just too diverse to provide an easy way to install a piece of software. Linux needs its own Microsoft to make something a standard at last.

Applications and bundled libraries

Posted Mar 22, 2010 16:06 UTC (Mon) by Frej (guest, #4165) [Link]

Just for the record, the windows way is also a bit crappy from a user standpoint.
With OSX it's better. For many apps you just drag the 'icon' to wherever you want. This simplicity is for users the same as when we want everything to be a file. It can be expressed as 'everything is just an object' for users. Of course this can't cover all cases, but the simplicity is attractive.
Why isn't a program just a file?

In short this way normal users actually have a chance of
1) Locating the program after 'installing it' (Since they decided the location)
2) Uninstall is just dragging same file (program) to trash.

But i agree, if you want to manage your computer (i think it's fun...) linux is for you. But if you don't, package systems are pretty annoying.

Applications and bundled libraries

Posted Mar 28, 2010 11:11 UTC (Sun) by cas (guest, #52554) [Link]

what you are describing here is not a system, it is a random, chaotic mess.

distributions are made by "big picture" systems people. they want the ENTIRE system to work smoothly as an integrated whole. i.e. they're mostly systems administrators rather than programmers (although there's a lot of crossover there's also a very obvious distinction between the two).

applications like firefox, chrome, etc are made by programmers. their focus is far narrower, all they really care about is their application - even at the expense of the larger system that it will be installed on.

this is not to say one kind of developer or the other is "better" - they're not, and BOTH are absolutely essential. but software works best when programmers and sysadmins work together, rather than try to work around each other.