| |||||||||||||
Exactly...Exactly...Posted Apr 2, 2012 19:12 UTC (Mon) by mathstuf (subscriber, #69389)In reply to: Exactly... by alankila Parent article: Free is too expensive (Economist)
I've been thinking that this is probably the way to go as well. You would have to get support pledges from anything that goes into "linux core version 1" unless you get another set of engineers to backport fixes and such (basically start a desktop-oriented Red Hat distribution).
The problem is that KDE and GNOME are upgraded in one huge dump and tend to not be forward compatible (4.8-built KDEAppFoo is unlikely to work without at least 4.8 kdelibs). I'm not sure if the KDE or GNOME communities could be convinced to split out the libraries from the applications in terms of API/ABI stability so that there would be just one version of kdelibs on the system instead of every application needing its own (instead of only those that actually need a newer version).
(Log in to post comments)
Exactly... Posted Apr 5, 2012 12:59 UTC (Thu) by alankila (subscriber, #47141) [Link]
What I would suggest is that both KDE and GNOME will upgrade in one huge dump, all applications and shared libraries together, and it should include pretty much every application user cares about. Taking GNOME as an example, there simply should not be significant gnome-libraries-using applications outside the main GNOME bundle.
It's clear from a statement such as this that this distribution method just wouldn't meet diverse needs very well, but on the upside it ensures that everyone gets the full gnome experience and all the apps, and we could install the stuff the day we hear about it on slashdot or LWN rather than waiting for a distro to package it first. It's obviously very different approach culturally.
Exactly... Posted Apr 5, 2012 18:25 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
I disagree. There are enough applications out there that *use* KDE but are not *part of* KDE (I worked on one, but they do exist). Some of the things offered in kdelibs make things painless (KPlugin, KParts, etc.) and if using them means you're tied to KDE releases, I would think that it's a hard decision between dropping those technologies or saddling up to KDE's release schedule.
It also means that you have to download *all* of KDE together. Of course, KDE could do like they do on Windows and have a package manager of sorts, but I don't know that that's the path that upstreams should be falling back on because that'd only bring us back to the same situation we have today (one supported version, keep updating or you get nothing new).
I don't think it'd be too onerous to get kdelibs and the core GNOME libraries pinned with a stable API and ABI (KDE has a policy, but it does get broken at times).
Of course, then there are projects like Boost which would need every version packaged in the base distro (expecting every project that uses Boost to deal with building and linking it on their own is asking a lot IMO).
Exactly... Posted Apr 5, 2012 20:11 UTC (Thu) by khim (subscriber, #9252) [Link] Of course, then there are projects like Boost which would need every version packaged in the base distro (expecting every project that uses Boost to deal with building and linking it on their own is asking a lot IMO). Why? Boost is most headers anyway, so not much space-savings from sharing. You only need things in core which can not be easily bundled with application. This is why I've always said LSB is brain-dead and 200% useless: the set of libraries it includes it totally insane. Instead of including essential, most important facilities first it starts with “mature libraries” and provides totally insane environment. It provides a lot of stuff: libjpeg and libpng, freetype and libxml, pango and gtk+. Pile of “nice to have” libraries which can easily be omitted without any ill effect. Yet it does not provide a way to output sound and video, play with system tray and show notifications. IOW: it does not provide “must have, you are dead if you don't include them” things! Why I say that libjpeg is less important then desktop notifications or sound? Because you can not bundle desktop with your application! And you can not bundle sound device with your application! Sure, you can poke around in /dev and/or /etc and try to find them - but this immediately moves out way outside of LSB promises. Freetype or libxml, on the other hand, can easily be bundled with your application if the need arises. Sure, it'll be nice to have them pre-installed to reduce download size, but they are not essential! If your notification interface requires use of dbus and gtk+ - then these should be included, of course (BTW LSB still does not include dbus), but sound and notifications should come first while boost comes last or not at all!
Exactly... Posted Apr 5, 2012 20:35 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
I agree that Boost is not on the top of the list of things this distro should care about. It was just the first example that came to mind which breaks the ABI with *every* release (if not in reality, the libraries get renamed for each version which makes it a moot point).
Yes, first, whatever is required to implement freedesktop.org standards, hardware, and external communications should be included (starting from the bottom with a kernel, systemd, udev, dbus, upower, udisks, *dm, pulseaudio, cups, firewall, etc.). After that, get the user-facing applications done in an upstream-oriented way (app storeish). After that, I, at least, would like to see common libraries be provided by the system which apps can assume exist. The set of libraries included could be part of the interface declared for a version.
The reasoning is that I would think that development should still be easy, so getting libraries and such provided by the distro should be possible instead of going around and downloading umpteen dependencies to start some project. Unless a "developer's" store makes sense, but I think distro packages do better than an app store model would. Of course, that is further down the road after user applications work.
Exactly... Posted Apr 5, 2012 21:07 UTC (Thu) by khim (subscriber, #9252) [Link] The reasoning is that I would think that development should still be easy, so getting libraries and such provided by the distro should be possible instead of going around and downloading umpteen dependencies to start some project. Oh, yeah. Ease of development is important, but this is separate issue. If developers know that some platform will give them they are ready to jump through a lot of hoops. I'm not sure distribution-supplied packages will be good for an app-store model, or perhaps it'll be better to use something like Gentoo, but it does not matter: if packages developed using different IDEs and different distributions can be used simultaneously then they don't compete with each other. In fact on Windows situation with libraries is extremely painful - yet this is most popular platform there is (Visual Studio is superb IDE, on the other hand). Development on Linux is not that bad - but it's pointless if the thing you've just developed can not be delivered to the end user without jumping through many extra hoops.
Exactly... Posted Apr 5, 2012 20:48 UTC (Thu) by apoelstra (subscriber, #75205) [Link]
I'm running firefox right now with no "system tray" or "notification system". Sure, video and sound are nice, but even the six packages you listed are enough for many web browsers, office suites, email clients, IM programs, newsreaders, terminals and calculators.
You can write development tools, network utilities, databases, window managers and crypto utilities all without stepping outside the LSB requirements.
Just because you cannot write Linux applications, and assume that your target systems are all iPods, does not mean that LSB is useless.
Exactly... Posted Apr 5, 2012 21:27 UTC (Thu) by khim (subscriber, #9252) [Link] I'm running firefox right now with no "system tray" or "notification system". Right. It's your choice. But that means that web sites can not use them, too. Amusingly, they can on Firefox on Android. Sure, video and sound are nice, but even the six packages you listed are enough for many web browsers Web browser without YouTube? Trashcan is over there. office suites Which can not use sound effect in presentations? Trashcan is over there. email clients Which can not notify you about new mail? Which can not open links in web browser? Is this a joke? Even GMail can do both (in Chrome, anyway). IM programs Without tray integration? Possible but ugly and inconvenient. More of the crap. newsreaders The same as with mail. Well, notifications are less important here. This one may actually be usable… if you'll forget that a lot of news today include video links. Out. terminals How will you terminal do the expected beep when calculators Well… that one is possible. I'm not all that sure why we'll want to have bazillion calculators. You can write development tools, network utilities, databases, window managers and crypto utilities all without stepping outside the LSB requirements. IOW: you can write some not desktop-related things. Yes. Probably. How is it related to desktop? On server RHEL rules, LSB is not needed there. Just because you cannot write Linux applications, and assume that your target systems are all iPods, does not mean that LSB is useless. It's useless on server (because it's not really needed there) and it's useless on desktop (it allows you to create program which can only excite someone who spent last dozen of years in coma), so what's the point? Where can you use it?
|
|||||||||||||