Losses at Mandriva

[Posted December 2, 2008 by corbet]

Two Mandriva contractors - Adam Williamson and Oden Eriksson have announced that their contracts are being terminated. These two developers are responsible for a great deal of the work which goes into the Mandriva distribution; as Oden notes: "Someone, or a couple of people will get their hands full (or not) maintaining the 1200+ source rpm packages I currently maintain. This is mostly server related stuff. For example the (L)AMP stack, to my knowledge the most complete on the planet, constantly growing and alive." The Mandriva community seems less than pleased; an online petition has been launched in an effort to get Mandriva to reconsider in Adam Williamson's case.

to post comments

Losses at Mandriva

Posted Dec 2, 2008 16:17 UTC (Tue) by briangmaddox (guest, #39279) [Link] (7 responses)

This has been going on since they booted Gael. Since then, Mandriva has continually begun to ignore the community which had built them up over the years. Decisions like this, along with comments from the new CEO, underscore that they current management has no idea that Linux thrives because of the community. They think that they'll break into the OEM market and into businesses, but they don't understand that Linux gets into these markets because of a community that pushes it and works to bring it in.

I think we'll see Mandriva still decline as a distro and in the end become nothing more than a distro used by a few companies in France. This really saddens me because I've been using it since Mandrake started as a repacking of Red Hat with much more current packages.

Losses at Mandriva

Posted Dec 2, 2008 16:41 UTC (Tue) by endecotp (guest, #36428) [Link] (6 responses)

> They think that they'll break into the OEM market and into businesses,
> but they don't understand that Linux gets into these markets because of
> a community that pushes it and works to bring it in.

I fear that's wishful thinking. Look at the OEM Linux situation on netbooks: they're mostly running distributions we've never heard of like Linpus and Xandros. I don't think they were chosen because of a community pushing them into place. Probably they got there because they had good salesmen who knew how to sell to those companies.

Losses at Mandriva

Posted Dec 2, 2008 16:53 UTC (Tue) by kragil (guest, #34373) [Link]

And that is part of the problem.

Nearly every Netbook has its own flavour of Linux. And they don't look or feel very similar. I really hope something like Moblin will become the defacto standard so that normal people will get more comfortable with Linux.

At the moment we have Xandros(KDE3.5), Ubuntu (Netbook Remix and generic), Mandriva(IDK), Linpus(IDK) and SLED(Gnome). Maybe even more...

Sounds a lot like the good old Unix days (when it was dying fast.).

Vendors need to come up with a some kind of standard if they don't want to pass on the Windows tax and want low return rates.

OEM distributions...

Posted Dec 2, 2008 17:41 UTC (Tue) by smoogen (subscriber, #97) [Link] (4 responses)

One of the big issues is that OEM's do not seem to be as big of a market as they were 10-20 years ago.While they still make a significant amount of the overall market.. individually they are very very small. People who run in this market usually have to be strong willed because its a constant fight with the other 'monkeys' to deal with the big apes who get most of the bananas.

I think the vast diversification of distributions on the OEM is a reflection of the diversification of the OEM's. Every OEM wants to have something that makes it different from the others.. to stand out, get more sales.. so they see the Linux distributions as being something that will make them stand out. If everyone shipped Red Hat, SuSE, Ubuntu or Mandriva.. then none of them would stand out as a 'different' buy. So instead they look at some distro, and use it as their brand-definer. This allows them to get the people who like that small distro.

No its not going to increase the usage of Linux, but OEM's aren't in that market nor are they a consolidated enough 'vector' to push that anymore.

OEM distributions...

Posted Dec 2, 2008 19:22 UTC (Tue) by vonbrand (subscriber, #4458) [Link] (2 responses)

Going after Xandros' (and other very minor distributions) enthusiasts won't get you very far; going for Fedora, Ubuntu, Debian, ... would be a much better choice.

OEM distributions...

Posted Dec 2, 2008 21:10 UTC (Tue) by jspaleta (subscriber, #50639) [Link] (1 responses)

Why? Why would any distro with an established userbase be a better choice?
Do the majority of the consumers in this market care about access to a large range of software that is the strength of a linux distribution?

It comes down to this. In a year, once the rush to market for netbooks is over and the device die-off begins... how will netbooks be marketted and sold? Will they be marketed as general purpose computers with the expectation to handle a vast array of software workloads? Or will they be marketed as gadgets like smart-phones or other mobile devices with a narrow set of expected functionality? I really don't think we know yet. The market is still in its infancy, with manufactures rushing to fill it up. Once the market gets crowded enough, competitive enough, we'll learn.

If these things end up being marketed and sold as mobile gadgets and not "computers" then there's absolutely no compelling reason for these oem's to use established linux distributions at all.... none. You line up cellphones and smartphones side by side across a number of manufacturers and how many different interfaces do you find? How much application variety do we find? Is the diversity of interface a problem? Is the narrowness of the application-space a problem?

If these things are the next generation of mobile gadget OEM's be better off using a base platform like moblin backed by coronary to build custom...differentiated...images for their specific brand of device instead of using an established distribution at all. The different interface designs become part of strategy to appeal to some portion of the very large market.

If these things end up being marketed more like laptops, there's probably pressure to use a common interface across devices..including other traditional laptops. But if that's the case, that pressure is going to also work against using linux and OEM's will end up being under consumer pressure to provide xp. The open source development model give Linux an advantage right now in that MS totally didn't see this market coming and wasn't prepared for it. But a year out from now, will linux continue to have that advantage if there is pressure for netbooks to be like traditional computers even if it means a bump up in price? I'm not sure.

It will be an interesting year. I expect 2nd/3rd quarters 2009 to be a bloodbath of competition in this space with some very innovative marketing efforts.

-jef

OEM distributions...

Posted Dec 2, 2008 21:46 UTC (Tue) by nim-nim (subscriber, #34454) [Link]

And additionally, will there be any netbook market next year at all?

Neither Intel nor AMD ever intended for netbooks to sell in the developing world. Their huge success happened at the cost of the low-end laptop segment. It would not take a lot of (concerted or not) inertia from them for the netbooks to die a slow death and margins to be restored.

Via is something else, but Via's ability to deliver was always questionable.

OEM distributions...

Posted Dec 2, 2008 20:50 UTC (Tue) by eru (subscriber, #2753) [Link]

Every OEM wants to have something that makes it different from the others.. to stand out, get more sales.. so they see the Linux distributions as being something that will make them stand out. If everyone shipped Red Hat, SuSE, Ubuntu or Mandriva.. then none of them would stand out as a 'different' buy.

On the other hand, these same companies also ship systems preloaded with Windows, which makes them equally similar buys, modulo some small customizations in utilities, logos and the selection of bundled apps (all of which obviously could also be done within a standard Linux distribution). So I'm not sure this is the explanation.

Losses at Mandriva

Posted Dec 2, 2008 16:55 UTC (Tue) by danielpf (guest, #4723) [Link]

I wonder if the adms at Mandriva deciding to fire prominent figures can imagine the scale of the negative image they send to potential customers and especially to software contributors, testers, etc.
As user of Mandriva since about 1999, this signal is showing me that, unless miracle, after 2009.0 I must plan to go elsewhere.

Losses at Mandriva

Posted Dec 2, 2008 17:15 UTC (Tue) by AdamW (subscriber, #48457) [Link]

Thanks for all your kind comments, guys.

In the interests of accuracy:

"These two developers are responsible for a great deal of the work which goes into the Mandriva distribution"

That's more than true in Oden's case, but not really true in mine. Most of my work is community relations; I only recently started to contribute as a packager and my contributions there are relatively small scale, certainly nothing compared to the quantity and relative importance of the packages Oden maintains. He looks after the LAMP stack, I look after a couple of Bittorrent clients...

But thanks!

Losses at Mandriva

Posted Dec 2, 2008 17:34 UTC (Tue) by MattPerry (guest, #46341) [Link] (51 responses)

> Two Mandriva contractors - Adam Williamson and Oden Eriksson have
> announced that their contracts are being terminated.

It's sad news to hear this. I hope they land on their feet and find work soon.

> Someone, or a couple of people will get their hands full (or not)
> maintaining the 1200+ source rpm packages I currently maintain.

As refined and advanced as Linux distributions have become, I am really surprised that we are still in the package distribution dark ages. It's nearly 2009 and each distro is still maintaining their own huge collection of applications. I don't understand why at this point we still have such duplication of effort between all of the different distributions. Wasn't LSB suposed to help solve this? Why aren't we at the point where there can be one or two packages (to accommodate rpm and deb) that can be installed on any LSB compliant distro?

Losses at Mandriva

Posted Dec 2, 2008 17:42 UTC (Tue) by tzafrir (subscriber, #11501) [Link] (3 responses)

Right. So what version of GTK must be packaged according to the LSB? Will the upcoming GTK 3.0 break it?

Yes, I know :-)

Losses at Mandriva

Posted Dec 2, 2008 21:00 UTC (Tue) by MattPerry (guest, #46341) [Link] (2 responses)

> So what version of GTK must be packaged according to the LSB? Will the
> upcoming GTK 3.0 break it?

Should it break it? I mean, can two different versions of GTK coexist? Is it possible to have the older GTK libraries available to support applications that might still require pre-GTK 3.0 functionality?

Losses at Mandriva

Posted Dec 4, 2008 10:20 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (1 responses)

This is a common argument but also a quick road to hell.

A. First, it's not about just keeping one other version of one well known lib available, you need to repeat with all the other libs apps written about that time commonly used (and recurse for all their dependencies).

B. Second, it's not "just keeping", it's also maintaining like fixing security problems and such.

C. Then, people will ask for N-x versions too, why stop at just N-1 ?

A. + B. + C. are already a major amount of work most people don't realise the scope of.

D. But then because you have several sets of versions available application writers will start doing strange stuff like relying on era N versions of library X and era M for versions of library Y (and they'll have unlimited arguments about why they should be allowed to do that, that basically boil down to "I have a bug with version N of library Y and can't be bothered to fix it").

That will in turn increase component interdependency complexity and distribution maintenance work.

A few years later when your distribution has ground to a halt because of letting application writers not make the effort to port to latest library versions, you'll need to kill some old stuff to liberate resources, and make all the delayed porting work happen anyway. And app writers will complain bitterly you're not keeping your part of the unsustainable bargain you were a fool to accept in the first place. (because of course their PHB will have refused to allocate resources do port anything to new versions since the old versions were available, so no matter how long you keep the old versions porting to new versions will always happen at the last time in crash mode).

Also multiple versions mean:
1. more mirror load
2. more bandwidth load
3. users that complain of update time and that the distro does not fit on their netbook anymore
4. users that complain because feature A in app X using lib version N is not available in app Y using lib version M
5. new bugs because of interactions between versions that were never supposed to be used together
6. new bugs because of applications getting confused and selecting the wrong component version
7. configuration hell because all this stuff uses slightly different configuration files, that will need to be kept in sync

And I'm sure there are many other points I've forgotten. But basically once you try to do it and realise all the implications you quickly reverse the decision. This kind of setup only looks good from the point of view of the people who don't need to deal with the maintenance fallout (developers who don't want to spend time porting to new versions and users of their apps who think it's easier to badger their distributor than getting the developers do their job).

Losses at Mandriva

Posted Dec 6, 2008 20:20 UTC (Sat) by dirtyepic (guest, #30178) [Link]

yes, we still have gtk+-1.2 and friends hanging around our repo, sleeping on the couch, cleaning out the fridge, etc. and as long as there are packages that haven't been updated to gtk+-2 and still work we won't be able to kick em out.

Losses at Mandriva

Posted Dec 2, 2008 18:00 UTC (Tue) by walters (subscriber, #7396) [Link] (7 responses)

Yeah, the duplication of effort is staggering. I see a few directions from which to attack the problem:

* Start replacing more of the user experience with PackageKit, gradually relegating apt/yum/etc to http and untar wrappers.
* Within each vendor, work to reduce the amount of duplicative gook needed to create a "package" (I tried this with CDBS in the Debian context)
* Shared core image: http://cgwalters.livejournal.com/20625.html

Losses at Mandriva

Posted Dec 3, 2008 10:14 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (6 responses)

That's the point of view of someone who never did any sustained packaging work and thinks packaging is just painting upstream tars in pretty distro colours.

Anyone who maintained a large set of packages during a significant length of time will tell you this is wishful thinking and most developer releases are nowhere near ready for direct user consumption.

Packaging is first and foremost taking care of all the little details developers don't get because they feel they are beneath them (legal audits, sane defaults, upgrade path, etc).

The core image thing is just the typical "it makes my head hurt, let's ignore it" developer response to managing modularity. It lead the Java world in an unmaintainable impasse for example (that's a core SUN guy writing it)
http://blogs.sun.com/mr/entry/packaging_java_code

Losses at Mandriva

Posted Dec 3, 2008 10:49 UTC (Wed) by dgm (subscriber, #49227) [Link] (3 responses)

I often think if wouldn't it be better for us all if distributions' packagers stopped acting as developers.

The time in which the amount of available software was scarce is well behind us. So why not simply _dump_ those packages that are not properly finished up?

Maybe it would be a saner world if packagers were just adding pretty colors to upstream tarballs.

Losses at Mandriva

Posted Dec 3, 2008 10:57 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (2 responses)

Because this is all interlinked stuff and killing one badly-behaved module will have cascading side-effects that will kill many other modules.

Packagers *hate* acting as developers. They just can not afford to wait for each individual developer to acknowledge his latest stupid change just made a quarter of the distro un-deployable.

Losses at Mandriva

Posted Dec 3, 2008 14:19 UTC (Wed) by dgm (subscriber, #49227) [Link] (1 responses)

Do you think that it's a great idea to keep distributing the software made by people that is unable to acknowledge when something stupid has been done?

Wouldn't it be better to be more selective? Please packagers, think of yourselves.

Losses at Mandriva

Posted Dec 3, 2008 14:26 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

I think you do nott realise there are almost no projects that do not goof sometimes and such a decision would only produce a nice embedded kernel-only distribution.

Losses at Mandriva

Posted Dec 3, 2008 17:04 UTC (Wed) by walters (subscriber, #7396) [Link] (1 responses)

Actually, I spent a long time in Debian doing package work, and I maintain right now a nontrivial number of things in Fedora.

I also happen to be doing upstream work for several of these things. And I strongly believe that the right place for the things you mention (legal audits, defaults, upgrade path) - *should be handled upstream*.

If you want to help Free Software, go upstream and help out there. Don't duplicate work in little downstream boxes.

Losses at Mandriva

Posted Dec 3, 2008 19:01 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

Actually, I don't mean to be disrespectful, and I don't want this to turn in a pissing match, but I hope you realise most packagers do not have the luxury of having a $dayjob at a big Linux company, with a backup team, packaging stuff they are paid to work on, and leveraging company IT resources for stuff they do in their spare time. Also none of your packages strike me as either having a high connectivity or being released by an entity not having the resources to push out clean QAed releases.

Which is in no way a criticism of your many qualities or work. You just seem to be in an extremely privileged situation for packaging, and rather unrepresentative of the many people that transformed a small RHL in a huge Fedora repository.

I work upstream-side too when possible. I say when, because this is not by any measure the general case, and your average packager do not have by any measure the resources or backup to change this situation. Or the luxury to just rewrite bits when an upstream is not helpful.

What you're asking for is the BSD model of highly controlled well-behaved core code. I happen to believe one reason for Linux' success is it made a big place for less-than-perfect joyous anarchy, and this was made possible by the packaging layer you complain of here.

Losses at Mandriva

Posted Dec 2, 2008 18:40 UTC (Tue) by AdamW (subscriber, #48457) [Link]

"Why aren't we at the point where there can be one or two packages (to accommodate rpm and deb) that can be installed on any LSB compliant distro?"

Because our packages are better, of course.

Losses at Mandriva

Posted Dec 2, 2008 18:43 UTC (Tue) by AdamW (subscriber, #48457) [Link] (34 responses)

"Why aren't we at the point where there can be one or two packages (to accommodate rpm and deb) that can be installed on any LSB compliant distro?"

Actually, I can give you an equally flippant but more true reply. Packages *are* distributions. This is the same question as "why do we have different distributions?" - because people want different distributions.

To take a random example, I maintain opensync for Mandriva. I use version 0.22, because it actually freaking works. Fedora has 0.3, because it's a bigger number and KDE 4 expects it to be there (never mind that KDE 4 cannot do anything at all useful with opensync).

If there were One True Opensync Package, who gets to maintain it, me or the Fedora guy? And which version does it get to be?

Sure, because I'm right and he's wrong, we can resolve that one (it would be 0.22 and he would be demoted and punished with a week's worth of bug triage work). But imagine that....TIMES TWENTY THOUSAND (deep booming movie announcer voice). That's how many little ego conflicts you'd have to resolve to have a single bunch of packages every distro would use. It's never going to happen. It'd be like herding several thousands cats and several thousand skunks, all at once.

Losses at Mandriva

Posted Dec 2, 2008 18:51 UTC (Tue) by avik (guest, #704) [Link] (8 responses)

If there were One True Opensync Package, who gets to maintain it, me or the Fedora guy?

The opensync maintainer.

Losses at Mandriva

Posted Dec 2, 2008 19:25 UTC (Tue) by AdamW (subscriber, #48457) [Link] (7 responses)

As a general rule, developers are *crap* at being package maintainers. This is why we have package maintainers. :)

Or were you replying in a fashion as flippant as my own? If so, good job =)

Losses at Mandriva

Posted Dec 2, 2008 20:07 UTC (Tue) by avik (guest, #704) [Link] (6 responses)

Only partially. I generally cringe at the duplication of effort involved in maintaining a distro.

Packaging support should be part of the tarball and worked up upstream, instead of being duplicated in every distribution. Many packages do come with rpm spec files (or the deb equivalent).

Losses at Mandriva

Posted Dec 2, 2008 20:11 UTC (Tue) by AdamW (subscriber, #48457) [Link] (4 responses)

...which, as I mentioned, are generally...not good. Anyway, as I said, it's still too glib an answer. Different distributions package things differently; that's the basic raison d'etre of distributions. Then each distribution has a user base who supports that distribution's way of doing things.

To take another example. Say an app has an optional dependency on a certain library. On the one hand, if you build against that library, you get a cool feature - but if you don't, you save the requirement.

A 'lean' distribution will want to not build against the library. A 'full fat' distribution will want to build against it. How do you reconcile that in the One True Package? You can't.

That's just another tiny example. The fundamental point is, multiple distributions exist because there are multiple valid perspectives on the best way to do things, which can't be adequately addressed in One True Package Set that everyone uses.

Losses at Mandriva

Posted Dec 3, 2008 8:40 UTC (Wed) by avik (guest, #704) [Link] (3 responses)

Use a plugin architecture.

I agree with your point, however.

Losses at Mandriva

Posted Dec 3, 2008 9:43 UTC (Wed) by jamesh (guest, #1159) [Link] (2 responses)

What do you do if the application doesn't use a plugin architecture? Do you boycott it until they rewrite things so that a single binary can fit all situations?

Losses at Mandriva

Posted Dec 4, 2008 15:20 UTC (Thu) by avik (guest, #704) [Link] (1 responses)

You work with upstream to add a plugin architecture. In the same way, if there's a bug, you fix it upstream to avoid duplication of effort.

Losses at Mandriva

Posted Dec 5, 2008 0:37 UTC (Fri) by nix (subscriber, #2304) [Link]

And if upstream says 'plugins? No way!' or is just impossible to work
with? (This is not academic: I can name several such projects, some of
critical importance, alas)...

RPM macro set hell

Posted Dec 12, 2008 15:37 UTC (Fri) by gvy (guest, #11981) [Link]

> Many packages do come with
...crap accidentally named *.spec :-[

It's fortunate if typical one loaded with mammoth's stdout like BuildRoot and %clean actually builds on say Fedora *and* openSUSE but ask packagers on RPMs with better macro set and they'll yell "CRAP!" at that.

I'm not even touching surface with stuff like control(8) which is developed and supported in Owl GNU/*/Linux and ALT Linux to let the packager limit the SUID/SGID scatter, and to let the sysadmin set up app modes in persistent manner. How can I propose to add %pre/%post scriptlets supporting that to upstream if that would blow up on mainstream cr... distros, that is?

Disclaimer: I maintain some 200+ packages in ALT Linux, most of my spec imports begin with "{,massive }spec cleanup" in %changelog (if there was any) and Fedora specs are usually last resort being usually, well, ugly :(

While at it, I'd not recommend Mandriva to anyone since "new order" fired Gael. Well, some people chose to work with them or use what they do; hope they understand before too long. Sad since there was nice feeling with a touch for details there... back in 7.x days.

Losses at Mandriva

Posted Dec 2, 2008 18:56 UTC (Tue) by timschmidt (guest, #38269) [Link] (10 responses)

Of course it can happen... In fact, it does. It just takes a lot of time. The locals call it Debian.

Losses at Mandriva

Posted Dec 2, 2008 19:26 UTC (Tue) by AdamW (subscriber, #48457) [Link] (9 responses)

Then why do so many people use Ubuntu?

Losses at Mandriva

Posted Dec 2, 2008 19:42 UTC (Tue) by fabo (guest, #49199) [Link] (3 responses)

because it seems easier to use and more sexy.

Losses at Mandriva

Posted Dec 3, 2008 10:36 UTC (Wed) by Los__D (guest, #15263) [Link] (2 responses)

because it is easier to use and more sexy.

There, fixed it for you. :p

Losses at Mandriva

Posted Dec 10, 2008 20:28 UTC (Wed) by jospoortvliet (guest, #33164) [Link]

No, he was right, it SEEMS easier and sexier. I'm not saying it's a bad
product, but it's not especially good or anything. Of course it's hard to
be objective about it, but at least I don't feel it is any better than
OpenSuse or Mandriva. You'll have a hard time come up with actual *proof*
that the *buntus are any better - at anything.

Sure, they make a lot of noise, but that doesn't mean they're good. They
fact they have better marketing doesn't mean their product is better. It
just means their marketing is better.

Illusions at Ubuntu

Posted Dec 12, 2008 15:40 UTC (Fri) by gvy (guest, #11981) [Link]

It might seem you fixed it but in fact you broke it. Somehow unsurprising.

Losses at Mandriva

Posted Dec 2, 2008 19:49 UTC (Tue) by briangmaddox (guest, #39279) [Link]

Because each Debian stable release is about five years old as state of the art goes? ;)

What difference between packages

Posted Dec 3, 2008 10:55 UTC (Wed) by rvfh (guest, #31018) [Link] (3 responses)

Or better: why does Ubuntu need to re-package the Debian packages? Even debianutils is re-packaged!

I know some packages do not exist in Debian in the first place... or so I was told.

What difference between packages

Posted Dec 3, 2008 19:06 UTC (Wed) by fabo (guest, #49199) [Link] (1 responses)

Ubuntu doesn't re-package every Debian packages.
Many packages in Ubuntu are "pristine" Debian packages.
Some packages doesn't exist in Debian in the first place but some Debian
packages doesn't exist in Ubuntu too.

What difference between packages

Posted Dec 3, 2008 19:48 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

Have any statistics as to how many 'pristine' debian packages by Ubuntu collections?

Are they more likely to be found in Ubuntu universe versus Ubuntu main or what? Are we talking like 1% of Ubuntu's main collection? Are we talking 10% of Ubuntu's universe? Or are we just talking about a handful of pristine debian packages?

-jef

What difference between packages

Posted Dec 7, 2008 19:02 UTC (Sun) by oak (guest, #2786) [Link]

> Or better: why does Ubuntu need to re-package the Debian packages? Even
debianutils is re-packaged!

Some reasons for doing this:

* Ubuntu does releases at different time from Debian (much more often).
This means that they sync with Debian at certain point and then kind
of "branch" that together-working set of package versions when stabilizing
it for a release (with security etc fixes). When work for the next Ubuntu
release starts, they again sync with Debian

* Binary packages re-compilation (if that's what you meant
with "re-packaging") is a must, just to make that everything really is
buildable and works together...

* There are also some differences in Ubuntu base system (Upstart several
releases before Debian, Python as an essential package which IMHO was
mistake, essentials should be minimized, not frivolously expanded etc).

Losses at Mandriva

Posted Dec 2, 2008 20:52 UTC (Tue) by MattPerry (guest, #46341) [Link] (11 responses)

> Actually, I can give you an equally flippant but more true reply.

I'm both saddened and disappointed that you feel my question was flippant. I posed that question as a serious inquiry into the current state of affairs of software distribution for Linux-based system. I'm not a programmer or developer; I'm only an end user. As an end user I am unhappy with the current state of Linux distributions.

As it stand now, users are held hostage by their distributions and lose choice and control. A non-technical user must use whatever packages are supplied by the distribution. If they upgrade their distribution then all of the applications, not just the core operating system, upgrade as well whether they want that to happen or not.

Are there ways to avoid this? Yes, a user could compile the package from source and install and maintain it that way. But that requires a certain level of technical sophistication and knowledge that the average computer user may not have nor care to develop. Even I, as a system administrator, tire of such detailed management on my home computers. A non-technical user would certainly be held hostage to whatever revisions of software ship with the distribution.

> If there were One True Opensync Package, who gets to maintain it, me or
> the Fedora guy?

Neither. The Opensync maintainers should maintain the package. The package repository should added as another entry into the distribution's repository list, or else someone could download the package and double-click to install the package.

I feel this way about all non-core OS packages, which would include all end user applications like browsers, office apps, media players, CD burning software, etc. There would potentially be thousands of repositories listed in one's apt or yum sources list rather than just one or two.

> And which version does it get to be?

It shouldn't matter as long as the packages of the older version were around and were compliant with whatever LSB revision your operating system supports. That way you can install whatever version works for you, even if it's an older version. End-users could run older software that is compatible with their system, no matter what reason they may choose to do so.

Losses at Mandriva

Posted Dec 2, 2008 21:25 UTC (Tue) by jspaleta (subscriber, #50639) [Link] (4 responses)

I think you underestimate the number of build time choices that application developers force people to make. And I think you grossly over-estimate the level of detail the LSB actually covers.

Not everything is a runtime discoverable option. Some options can only be chosen at build time. Those options pull in other libraries as dependencies...libraries with version specific API's and ABI's. Holding onto all possible versions of all possible libraries to try to satisfy thousands of individual application repositories is a maintenance and security nightmare.

-jef"cringes at the though of thousands of individual python based applications running their own repositories...and having users trying to rely on the fragility of that arrangement across a python version jump in a distribution"spaleta

Losses at Mandriva

Posted Dec 3, 2008 2:45 UTC (Wed) by madscientist (subscriber, #16861) [Link]

Not only that, but libraries are actually the easiest problem to solve. Yes, obviously you can always just install enough versions so everything can start properly with its preferred version.

But, on a modern system the most interesting and difficult interaction is at runtime, as various programs talk to each other, through dbus or pipes or sockets or whatever. Trying to keep all that messaging 100% backward compatible is a nightmare and there's no simple solution to this problem: newer applications expect the services they interact with to have newer features: that's why we upgrade, after all. That's why you generally need to upgrade the entire desktop environment, because those applications and applets are strongly linked.

And, although maybe it's appropriate for LWN, you are completely ignoring the large number of non-Linux platforms that most upstream developers support. Requiring upstream developers to be fluent in not just RPM vs. DEB, Red Hat vs. OpenSUSE vs. Fedora vs. Gentoo ebuilds vs. Ubuntu vs. Slackware vs. PackageKit, but to ALSO understand FreeBSD ports and the differences building packages for the *BSDs, Solaris, HP-UX, AIX, etc. is completely infeasible. And upstream developers are simply not willing to compromise the software in Linux-specific ways, the way package maintainers often need or want to. That's no one's fault: it's the result of perfectly legitimate differences in focus and priorities.

As an end-user I'm sure it seems like a lot of wasted effort. But believe me, if you were involved in the guts of these efforts, whether on the package maintainer side or the upstream developer side, you would (modulo the inevitable conflicts that always arise) agree that there's no really practical alternative and there are even advantages to doing things this way.

ObDisclosure: I'm an upstream developer for a common software package.

Losses at Mandriva

Posted Dec 3, 2008 22:15 UTC (Wed) by louie (guest, #3285) [Link] (1 responses)

I think you underestimate the number of build time choices that application developers force people to make.

That sounds like a problem to fix, not a problem to work around.

It's not like these upstreams are proprietary. If opensync 0.3 is broken, that indicates the people doing packaging downstream should have been spending their time doing QA upstream. Ditto for KDE4's dependencies, python's upgrades, etc. What you're saying is 'upstream is stupid, so we have to spend thousands of man-hours... not fixing upstream.'

(And yes, I have thousands of hours of experience doing both upstream and distro-level work, and like walters, I agree that the best option is always doing work upstream. The current arrangement is maddeningly wasteful and shouldn't be necessary for any but the most core packages.)

Losses at Mandriva

Posted Dec 3, 2008 23:00 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

All compile time choices are a QA issue? Hmm that's an interesting stance to take. I wouldn't go that far. Making some dependencies optional at compile time can be a deliberate design choice.

Are you saying that all optional functionality across all applications and projects which relies on external libraries should be coded as runtime detectable features and that compile-time linkages to optional libraries should be forbidden on the grounds of QA?

-jef

Losses at Mandriva

Posted Dec 5, 2008 4:40 UTC (Fri) by MattPerry (guest, #46341) [Link]

> I think you underestimate the number of build time choices that
> application developers force people to make. And I think you grossly
> over-estimate the level of detail the LSB actually covers.

I imagine you are correct on both counts. I just see it being done successfully with Wine and imagine it could be done with other software as well. I hope there would be a way to provide what I want at some point in the future, at least for desktop applications.

Losses at Mandriva

Posted Dec 3, 2008 4:14 UTC (Wed) by flewellyn (subscriber, #5047) [Link]

I'm both saddened and disappointed that you feel my question was flippant.

I believe he was speaking of his other reply, "Because ours are better", as the "equally flippant" one. Not your question.

Losses at Mandriva

Posted Dec 3, 2008 4:36 UTC (Wed) by jamesh (guest, #1159) [Link] (1 responses)

What do you do when the upstream package maintainer doesn't want to maintain the package for you?

In the situation Adam mentioned, Fedora was using an older OpenSync package in order to work with another package they are distributing. Could they really expect the upstream maintainer to provide an up to date package for software they consider obsolete? How about handling security issues?

Now consider the other packages that might rely on OpenSync. Lets say that they produce different binaries when compiled against the different versions of OpenSync. Should the distribution expect all these upstream package maintainers to produce a second version of their package?

These are the sort of integration problems distribution packagers face all the time, and it doesn't seem sensible to expect unaffiliated package maintainers to place the same importance on the problems.

Things are a bit simpler at the application layer, where upgrades won't break other parts of the distro. It isn't always simple though, with applications like Firefox providing components that get reused by other packages.

Losses at Mandriva

Posted Dec 4, 2008 18:59 UTC (Thu) by AdamW (subscriber, #48457) [Link]

Just to note, you inverted the example. I use opensync 0.22 in Mandriva because it's the stable release that works and I actually *test* that stuff. 0.3 is the current entirely unstable development branch that cannot do anything useful and frequently eats people's data. However, several distributions (including Fedora) didn't bother to read the big DON'T USE 0.3! warning at www.opensync.org and packaged 0.3 anyway. And, consequently, their packages are utterly useless.

Losses at Mandriva

Posted Dec 3, 2008 10:15 UTC (Wed) by Los__D (guest, #15263) [Link]

I'm both saddened and disappointed that you feel my question was flippant.

I think he's referring to his own Because our packages are better, of course, not your post.

Losses at Mandriva

Posted Dec 4, 2008 19:05 UTC (Thu) by AdamW (subscriber, #48457) [Link] (1 responses)

As others have noted, it was my first reply I considered flippant, not your question. :)

In general I would agree with jspaleta's reply. I think the likelihood of anyone believing that a world where developers maintained all the packages would be a good one has a directly inverse relationship to the number of packages that person maintains. =)

I am currently working on migrating Mandriva's development branch from Tcl/Tk 8.5 to Tcl/Tk 8.6. This involves updating a bunch of rather obscure applications that use Tcl.

When you do this kind of thing on a regular basis you get a deep and meaningful understanding of just *how* crack-addled a set of build scripts a really determined developer can write, when they set their minds to it. It's not pretty.

OK, yes, I could carefully re-implement all these build scripts in autotools or cmake or something so that they will work across all distributions and Solaris and contribute them back to upstream. Hell, I probably should. If the build script is mostly sane, I fix it and send the patch. But if it's a gigantic ball of pain, I just hack it up so it works for building a Mandriva package (but would not work at all on any other distro or if you were building from source), and move on. Because it needs to get done, and if I spent all my time re-writing shit build scripts I'd never actually get the original task (migrate to Tcl 8.6) done.

Plus, half of these projects have been dead for years. But we still need the app, because someone out there still uses it, and no-one ever bothered to write a modern replacement because the old thing still more or less works. So where would I send the fix?

Basically, when the happy-clappy "let's have one awesome universal package base!" theory runs into the mundane reality of developers who have no clue how to install things properly and years-dead projects, it dies in a hurry.

Losses at upstreams

Posted Dec 12, 2008 15:53 UTC (Fri) by gvy (guest, #11981) [Link]

Weeeeell, probably some sort of "adoptarium" for the needed part of that orphanage might help. IIRC there was something created or announced on LWN several months ago, but I've forgot the name already (ouch!).

Consider dhcpcd which was effectively a dead upstream until Debian and Gentoo maintainers decided to br^H^Htake it over.

Culture of wrappers and workarounds

Posted Dec 5, 2008 14:33 UTC (Fri) by nhippi (guest, #34640) [Link] (1 responses)

> To take a random example, I maintain opensync for Mandriva. I use version 0.22, because it actually freaking works. Fedora has 0.3, because it's a bigger number and KDE 4 expects it to be there (never mind that KDE 4 cannot do anything at all useful with opensync).

This is actually part of the disaster created by distributions. Instead of fixing things (like opensync 0.3), distributors choose to revert to old versions. Or create wrappers/horrible patches.

A great example is X. For years and years distros competed on who had the shiniest XF86Config generator scripts. Each and every distro duplicated that work. Then finally one day upstream went and implemented autoconfiguring. All that duplicated work.. down in history.

Had distributors worked from the beginning withing X to add autoconfiguring and sane defaults instead of attempted to add value to their own distro, how much further would be today?

Distros seem to thrive with the "Dont fix it, workaround it. Or add a wrapper. Whatever you do, don't co-operate with upstream." culture.

Culture of implementing on crack

Posted Dec 12, 2008 15:56 UTC (Fri) by gvy (guest, #11981) [Link]

> Then finally one day upstream went and implemented autoconfiguring.
...breaking things for everyone. Yes, from modelines to 96dpi on ati and 120dpi screen.

Theory and practice are closer in theory than in practice. And distros are closer to users than upstreams usually. (implementors and supporters are closer yet, so there's at least one more similar round)

Losses at Mandriva

Posted Dec 3, 2008 9:54 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (1 responses)

Actually, the level of work needed to maintain a large package pool has been causing a slow consolidation in the past years. We're no longer in the situation where every first-rank and second-rank distro is totally independant, and big packaging projects like Debian of Fedora now have several derivative projects gravitating around them.

UnitedLinux was an effort to set up a third gravity point, it failed first and foremost because of the SCO incident but one may wonder if going at it through business agreements was the right angle at all in the first place. Debian and Fedora succeeded by playing the community card.

OpenSuse is a new effort from Novell to set up this third point, it's not clear yet if it's succeeding or not.

Mandriva's current problems are largely due to the UnitedLinux explosion and its own failure to recognize the trend and become part of a larger alliance.

If you want to see actual Dark Ages stuff, you can look here
http://blogs.sun.com/mr/entry/modular_java_platform
Sun discovering in 2008 packages and automated dependency resolution may have some use.

...automated deps resolution...

Posted Dec 12, 2008 16:02 UTC (Fri) by gvy (guest, #11981) [Link]

Well, you might want to have a look here then (also a bunch of rpm-build-* nearby).

Losses at Mandriva

Posted Dec 6, 2008 20:46 UTC (Sat) by dirtyepic (guest, #30178) [Link]

because a package is not a static cog or block that you stack together with other blocks to create a distro. there is no one way to configure a package that is the "correct" or "right" way. different people have different needs. one distro might disable support for non-free media formats in a package in line with their philosophy of free software, while another might be focused on everything working out of the box and not be concerned with proprietary formats. other distros let the user decide, either by modularizing the package or providing separate packages for different configurations. source distros generally have a way for the user to change options at build time.

it's a far cry from one size fits all, and that's a good thing as it's what allows the flexibility and freedom we all enjoy to be possible.

Losses at Mandriva

Posted Dec 2, 2008 20:42 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

How does Oden maintain that many packages? How does anyone? Is he really
an army of clones (and they're letting one go) or has he found a way to go
without sleep and fold time so that he lives a month every day?

Losses at Mandriva

Posted Dec 4, 2008 21:48 UTC (Thu) by AdamW (subscriber, #48457) [Link]

Well, a lot of them are modules for Apache or PHP that are very similar to each other and can be maintained in batches. But yes, it's a lot of work.

Losses at Mandriva

Posted Dec 4, 2008 7:19 UTC (Thu) by k8to (guest, #15413) [Link]

Thanks nim-nim for your clarifying points about how packaging is for better or worse essential and enables the high success envieronment we call Linux.

So long guys! You'll be missed but not forgotten ...

Posted Dec 5, 2008 2:57 UTC (Fri) by ghmitch (guest, #14012) [Link] (2 responses)

Mandriva has lost a lot of great people over the years, but this is not the end of Mandriva OR the end of the world. Anybody remember when they dismissed Deno (Denis Havlik)? Lots of us found that pretty painful. And then Adam came on board and picked up where Deno left off, and did a great job as well. One of Mandriva's biggest problems is also one of its biggest success stories. Mandriva has a great ... Great ... REALLY GREAT user community. The way Mandriva interfaces with their users is really unique in the Linux world. And this causes a big problem because it works so well that we users forget that Mandriva is really just another big corporation. We expect that they are a part of the same community we are with the same values and expectations. But on the other side of the curtain hidden from our view lies another world. The corporate world of professional strategists, consultants, and miscellaneous bean counters who are looking at very different factors than we are. And that brings some real disconnects at times and this is one of them. At various points in the past my life has intersected with both Adam and Oden in dealing with various issues Linux. All of those were good and memorable experiences and even though I haven't really been all that active in the Mandriva community for years, I will miss them both. But life changes. There were changes when Mandrake teamed with Connectiva (another great Linux name) and became Mandriva. Now Mandriva has teamed up with Turbo and we now have the birth of Manbo Labs. All of this brings new changes. I have no idea whether or not this is behind the departure of Adam or Oden, but my point is that there is a lot that goes on at the corporate level that we neither see nor comprehend. And although the bigwigs make their share of mistakes, we need to be cautious in judging them, since they are dealing with issues that are really out there. So I wish Adam and Oden the very best, I know they will both not only be successful, but also move up to new heights through this transition. But I also wish Mandriva the best. I hopped on this train with the Linux Mandrake 6.0 Power Pack and it has been a great ride! Sure there have been some bumps in the road, but we've all come a long way and I believe with all my soul that Mandriva's best days are still ahead. So, so long guys and thanks ever so much for all of your hard work on behalf of the amazing Mandriva community! - George Mitchell

So long Mandriva!

Posted Dec 12, 2008 16:04 UTC (Fri) by gvy (guest, #11981) [Link] (1 responses)

> The way Mandriva interfaces with their users
> is really unique in the Linux world.

orly?

So long Mandriva?

Posted Dec 13, 2008 23:56 UTC (Sat) by ghmitch (guest, #14012) [Link]

I've been around (in the Mandriva community) for nearly a decade now, and I've been hearing this nearly from the beginning. The discontent started in earnest with Mandrake 8.0 and has waxed and waned ever since. During that time they have dismissed some of their most popular developers and user advocates and that hasn't helped. But still they plod on and their software just gets better and better. So I really doubt that they will being going away any time soon.