| |||||||||||||
GUADEC: GNOME OS conversationsGUADEC: GNOME OS conversationsPosted Aug 23, 2012 7:23 UTC (Thu) by brother_rat (subscriber, #1895)Parent article: GUADEC: GNOME OS conversations
The trouble from GNOME's perspective is that distribution packages are typically delivered six months after GNOME drops its stable releaseI'd say the trouble from anybody else's perspective is that GNOME is producing something that appears to take six months to package and then transition over to.
(Log in to post comments)
GUADEC: GNOME OS conversations Posted Aug 23, 2012 8:17 UTC (Thu) by micka (subscriber, #38720) [Link]
And those six months doesn't even include the time required to choose whether you want to make the transition or not.
GUADEC: GNOME OS conversations Posted Aug 23, 2012 9:05 UTC (Thu) by drag (subscriber, #31333) [Link]
Gnome isn't the only software that experiences this sort of problem.
It's a chronic problem for the kernel and device drivers also. (but it's not isolated to just Linux and Gnome either)
Say you have open source drivers for video cards.. this will often require updated Mesa libs, some X work, updated kernel DRM, in addition to the actual DRI drivers. The driver developers can hack on new features, improve performance, fix bugs, and do all sorts of stuff to improve the drivers but almost nobody can benefit from their work immediately. It will take six months to a year before the improvements filter down to end users through the distribution channels.
Meanwhile proprietary device drivers that provide a out-of-band method of installation can get their improvements new device support out to the users immediately. Also beta programs that are not any harder to participate in then just installing the regular drivers. They are a pain in the ass to install sometimes, but are also going to be much easier then if you are going to try to use the latest open source drivers.
The same problems exists with Wifi drivers and anything else kernel related. It's a big enough problem that companies like Dell had to create their own solution for back porting drivers to existing distributions so that they can get proper hardware support and fixes to their customers.
This is a issue for any software that Linux users may want to use. For example:
How many of those applications described in that article are available at their latest release on your current distribution?
If you are using Gentoo or Fedora 17 you will have the ability to easily install the latest version of LMMS. However if you are a Ubuntu user you can't do that through apt-get. Maybe Ubuntu studio will have the latest version, but you don't get that with the regular Ubuntu release. You don't get it if you are using Fedora 16 either.
What if there a bug that makes a user's laptop not suspend any more and people need this functionality? This means that they can't run new versions of any of their software until the distribution fixes it. Which means that even if the Linux kernel devs fixed it last month there could be another 2 or 4 months before the fix makes it to that user. And during that time they can't install any newer versions of the software they use.
And if you are actually able to use the latest version of a distro without hardware conflicts you still have to upgrade _everything_. You can't just use arbitrary versions of whatever software you want to use. You can't mix a older version of Gnome with a newer version of _anything_, regardless of out dependencies are setup.
This isn't the sort of thing that people tolerate on any other OS.
(Poor Ardour has a begging page for donations if you install the software from their website, but if you do it via apt-get or yum you have no clue that the developers are asking for donations and there is no simple or easy way to perform such donations. This makes developing commercial open source software extremely difficult and a very unlikely profitable.)
Therefore any piece of Linux software.. whether it's drivers, games, or applications, absolutely must provide their own out-of-band solution for providing binaries if they expect Linux users to use it any time in the next six-eight months. Any distribution supported scheme is going to be distribution and release-specific.
Unfortunately none of the solutions application developers come up with are really that good. Either they require massive amounts of work, like providing application-specific repositories for each Linux distribution and distribution release that people are likely to use. Or provide tarball downloads of software built on Ubuntu and just hope that it works and that users will not just give up when it doesn't. Or use special installers that are full of hacks and weird functionality that may or may not work due to bugs in the installer and the fact that you have to install the installer to get the installer to work.. at any point you may run into random dependency issues that are completely and utterly outside of your control.
It's all really quite painful.
GUADEC: GNOME OS conversations Posted Aug 23, 2012 9:31 UTC (Thu) by njwhite (subscriber, #51848) [Link]
It sounds like the sort of out-of-band install solutions you're talking about could be dealt with easily using static binaries. I do that for a little project of mine (using musl-gcc), and it works well.
GUADEC: GNOME OS conversations Posted Aug 23, 2012 13:11 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
> It sounds like the sort of out-of-band install solutions you're talking about could be dealt with easily using static binaries. I do that for a little project of mine (using musl-gcc), and it works well.
For many (most?) libraries yes. E.g. though if you do that with Qt it is hard to get your application to look similar to other applications on the desktop (and it is quite big too).
GUADEC: GNOME OS conversations Posted Aug 23, 2012 10:37 UTC (Thu) by talex (subscriber, #19139) [Link]
> Therefore any piece of Linux software.. whether it's drivers, games, or applications, absolutely must provide their own out-of-band solution for providing binaries if they expect Linux users to use it any time in the next six-eight months. Any distribution supported scheme is going to be distribution and release-specific.
> Unfortunately none of the solutions application developers come up with are really that good.
http://0install.net is designed to address this problem. It downloads tarballs (source or binary), manages multiple versions, uses GPG signatures, handles shared libraries, and supports dependencies downloaded itself or from the distribution (if sufficiently up-to-date) using PackageKit.
It's also included in most distribution repositories already (as the zeroinstall-injector package): Debian, Ubuntu, Fedora, OpenSUSE and Arch, at least. And it also works on Windows and Mac OS X.
I haven't seen it used for GNOME, but e.g. on most distributions you can run the ROX desktop's file manager like this:
$ sudo apt-get install zeroinstall-injector
What else would it need to support GNOME's requirements?
[ note: I am a 0install developer ]
GUADEC: GNOME OS conversations Posted Aug 23, 2012 11:37 UTC (Thu) by jpfrancois (subscriber, #65948) [Link]
Regarding running recent kernel, onn ubuntu you can install current kernel very easily. I have a 3.4 and 3.2 kernel on my 10.04 ubuntu, and I just downloaded a .deb
GUADEC: GNOME OS conversations Posted Aug 26, 2012 5:54 UTC (Sun) by cas (subscriber, #52554) [Link] Therefore any piece of Linux software.. whether it's drivers, games, or applications, absolutely must provide their own out-of-band solution for providing binaries if they expect Linux users to use it any time in the next six-eight months. Any distribution supported scheme is going to be distribution and release-specific.You've convinced me. I really want to return to the 1980s. Spending days or weeks downloading, compiling, installing and resolving conflicts and version incompatibilities for every program or library I wanted to install was so much more fun that running apt-get.
GUADEC: GNOME OS conversations Posted Aug 31, 2012 17:15 UTC (Fri) by philomath (guest, #84172) [Link]
There is a middle way, such as Arch Linux.
GUADEC: GNOME OS conversations Posted Aug 23, 2012 10:02 UTC (Thu) by ebassi (subscriber, #54855) [Link] I'd say the trouble from anybody else's perspective is that GNOME is producing something that appears to take six months to package and then transition over to. you seem to be operating under the delusion that it takes six months to package GNOME; the development cycle of GNOME is six months; all micro releases are packaged by distributions to be tested during the development cycle of the distributions itself in order to receive QA and to apply distribution-specific patches. sadly, this is not enough, unless you have a QA team for every distribution and for GNOME. the delta between design, development, and user testing is still too damn high - and after that you also need to deploy to the actual users. this does not apply to GNOME alone, by the way; it's something that's common for every complex project - the Linux kernel, Xorg/Mesa, KDE, you name it.
|
|||||||||||||