| |||||||||||||
Exactly...Exactly...Posted Mar 31, 2012 2:10 UTC (Sat) by Pc5Y9sbv (guest, #41328)In reply to: Free is too expensive (Economist) by rqosa Parent article: Free is too expensive (Economist)
You could always make a very portable Linux application binary by ignoring the distribution-specific packaging system and all the shared-library conventions of such a distribution. Make a statically-linked executable and self-sufficient installation tree, depending on little from the host OS except the kernel ABI and the barest minimum of POSIX and/or LSB stuff.
Follow some conventions like searching environment, /etc/yourapp/, ${HOME}/.yourapp/, and /opt/yourapp/ for some configuration data to override the compiled-in defaults (even up to looking at the dirname of argv[0] to locate yourself). In the past you might need to use IPC to talk to the X server, etc. Today I'd recommend running an embedded web service so the UI can be exposed over loopback (or network, if the user wants) to run in a browser.
This seemingly archaic distribution approach is how Apple and Google have approached the bundling problem. They have extremely flat catalogs of applications, each of which is essentially standalone so there is no need for complex inter-package dependency management, nor questions of where a myriad other third-party components can be found on disk. This makes automatic installation of applications very easy, without the overhead of a classic Linux distribution needing to carefully package and quality-check all of the applications as parts of a monolithic whole. Given this approach, they also extended the platform ABI a bit, without trying to solve the entire OSS dependency problem. On the downside, you lose the storage efficiency and simultaneous patch/update capability for common third-party dependencies, as each application is now bundling its own copy of such third-party components.
(Log in to post comments)
Exactly... Posted Mar 31, 2012 9:44 UTC (Sat) by rqosa (subscriber, #24136) [Link] > This makes automatic installation of applications very easy, without the overhead of a classic Linux distribution needing to carefully package and quality-check all of the applications as parts of a monolithic whole. But it has its drawbacks, too. In particular, it leads to the situation where you have (for example) 20 applications, each of which uses the same 20 libraries, thus requiring you to have 380 redundant copies of libraries installed. ISTR reading a blog post by a Calligra developer porting Calligra to Android, saying that this issue of massive redundancy meant that you would run out of memory fast if you tried to run multiple Calligra apps at once. And of course there's also the issue that a security vulnerability in one of those libraries means that every app using it will need to issue a security update — and the app developer might not even rebuild the app with the fixed library, leading to vulnerabilities remaining unfixed for a long time. (This has happened repeatedly with zlib in particular.)
Exactly... Posted Mar 31, 2012 11:05 UTC (Sat) by rqosa (subscriber, #24136) [Link] (I haven't been able to find the blog post I thought I remembered seeing. Maybe it was about some other KDE/Qt software on Android? Also, maybe the problem I remember reading about was actually running out of SSD storage space for installed apps, rather than running out of RAM.)
Exactly... Posted Apr 1, 2012 9:17 UTC (Sun) by alankila (subscriber, #47141) [Link]
The solution to this problem is to have a shared core of libraries which change slowly enough that they can be reasonably dumped into the install media of the linux distribution itself, and frozen afterwards (in terms of functionality/abi). This cuts down the number of libraries you do have to bring with the application bundles, and defines a common binary interface for all software. In practice this requires very strict and careful maintenance, and ideally we could get a common set of baseline binaries ("linux core version 1") shipped by all distributions.
Secondly, the application bundles should provide multiple applications. For instance, if you were to install new version of KDE or GNOME by the application bundle method, it better all be in 1 bundle. This, in turn, makes it possible to ship shared libraries in the bundle, and therefore reaping the memory saving benefits, and therefore it is probably the method that the Calligra suite should be using. Maybe some amount of system dependencies would be acceptable, such as X libraries or glibc, to limit the size of the bundle somewhat. (Just handwaving the problems away here, obviously. It's difficult to do until we get the "linux core version 1" defined and deployed.)
Exactly... Posted Apr 2, 2012 19:12 UTC (Mon) by mathstuf (subscriber, #69389) [Link]
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).
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?
Exactly... Posted Apr 1, 2012 20:43 UTC (Sun) by Pc5Y9sbv (guest, #41328) [Link]
I see the loss of library security updates as the biggest drawback to these vertical bundles. Many of us long-time FOSS users, developers, and sysadmins strongly prefer the distribution model with centralized patch management. It has evolved to address a very important need of the community to balance different integration goals of tens of thousands of developers and millions of users. For 95% of the software I use, if it doesn't exist in my chosen Linux distribution, it doesn't exist for me. The way to get your software to me is to get the attention of the distributors, cajole or employ package maintainers, and get it integrated into the system. Even if we erased the technical packaging/bundling challenges, I'd want this anyway. I want you to pass the basic sanity checks that the distributor imposes to validate that you are a viable project.
Every OSS developer (me included) has a built-in bias to feel that our latest code is the best thing, worth whatever risks or compromises it takes to get it on the system. But in almost every case, OSS releases are really beta software, where the community does much of the QA by accident as they use it. This is inherent to developing software without big commercial budgets. However, most users only have a small number of domains where they should really be a beta tester. And they need to be aware of the risk it reflects on whatever they are actually trying to achieve. Doing that for all the applications on a typical Linux system is just asking for trouble, for an experience of constant bugs and mistrust. I absolutely DO NOT want to disintermediate my consumption of software, leading to hundreds or thousands of independent developers trying to make software update policy decisions for me.
In my 20 years of using Linux, I've noticed prognosticators issue their "big picture" statements and anoint their favorite trends as the indisputable future. They've often seemed pretty myopic, as I've noticed that FOSS evolves a lot more organically than that, due to the myriad interests and motivations of all the contributors. I see that we're happily infusing FOSS Into every space from high-performance computing, to Internet servers, to routers, mobiles, and embedded systems. And this is happening due to real benefits to all the businesses involved, not out of some subversive religious effort. I feel fortunate that I've also been able to use it on workstations and laptops for my entire career. But if "Linux" fades eventually, I feel confident that it will only be because we've shifted our attention to an even more flexible FOSS platform, and it still won't matter if it has been the year of Linux on the desktop, or tablet, etc.
Exactly... Posted Apr 7, 2012 19:00 UTC (Sat) by man_ls (subscriber, #15091) [Link]
Thanks for your post, it sums up my thoughts nicely.
Do not yield to the flower of the day, be it mobile or phone. I would very much prefer having debian on my phone than android on my desktop!
Exactly... Posted Apr 9, 2012 1:03 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
You can have it. Ubuntu works fine in a chroot on my Galaxy S.
Go on, install it and use it.
Exactly... Posted Apr 3, 2012 13:36 UTC (Tue) by RCL (guest, #63264) [Link]
> it leads to the situation where you have (for example) 20 applications, each of which uses the same 20 libraries, thus requiring you to have 380 redundant copies of libraries installed.
Somehow people seem not to care about RAM when they are writing their applications in languages like Python, Java, C$ or using databases to store local settings where simple text file would be enough (yes, Akonadi, I'm looking at you).
So yeah, I prefer 20 C/C++ "standalone" applications as opposed to fragile mess of higher-level language apps that have to have 30 dependencies installed to just start.
Exactly... Posted Apr 6, 2012 16:08 UTC (Fri) by krake (subscriber, #55996) [Link]
"or using databases to store local settings where simple text file would be enough (yes, Akonadi, I'm looking at you)."
Just to clarify for other readers of this read: Akonadi stores its settings in INI-style text files in $XDG_CONFIG_HOME/akonadi
KDE based Akonadi clients also store their settings in INI-style text files in $KDEHOME/share/config
It might be possible to use a simpler format than INI-style but for most developers it seems to be simple enough
|
|||||||||||||