Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
I have seen that happen with OSX. Quite badly, in fact, and more than once.
The article is correct
Posted Mar 31, 2012 7:55 UTC (Sat) by danieldk (guest, #27876)
(PS. no personal attack intended)
Posted Mar 31, 2012 7:56 UTC (Sat) by danieldk (guest, #27876)
Posted Mar 31, 2012 9:30 UTC (Sat) by boudewijn (subscriber, #14185)
There's no hint in what I said of that: there's no hint of me excusing bugs in Linux, no hint of "they are broken, so it doesn't matter we are broken as well". Of course we have to fix issues and make Linux the best user environment there is.
Sure, Windows 7 is a ghastly mess and Windows 8 will be worse, and OS X is broken in many ways -- but while that's a fact, it's a fact that is completely irrelevant for whether the Linux desktop is perfect. It ain't, but lots of people are working really hard in many ways to get there.
The mindset that _I_ object too, strongly, is the parrot-talk about how linux will never succeed. We succeed, we are succeeding, and it will only get better. As long as people work on it, instead of sitting down and claiming it's a lost cause, let's give up.
I detest defeatism.
Posted Apr 1, 2012 9:54 UTC (Sun) by danieldk (guest, #27876)
Linux has already succeeded to a large extend in servers, routers, DVRs, and phones. Linux could also succeed on the desktop with some adjustment. Some things that are required:
- No crazy desktop changes in stable versions. I do like GNOME 3 and Unity, but the changes should've been more evolutionary.
- A stable ABI that is shared between all Linux distributions.
- An easy way to install third-party software. As easy as drag and drop. I know that this is technically possible today, but it requires the previous point plus maybe something like fat binaries. Also, the process of creating an application bundle should be easy.
- The core of the system and third-party applications should be decoupled more. It should be easy to continue running, say Debian Stable or Ubuntu LTS, while being able to upgrade your applications without upgrading the base system, X11, toolkits, or the desktop environment.
I certainly believe that Ubuntu's PPAs (and SUSE's build system) have made live a bit easier for everyone: as a developer I can simply put a source package in the archive, and packages are built for i386 and amd64, and it is relatively easy to maintain packages for multiple Ubuntu versions. But it is still not trivial for a non-expert user to add PPAs, let alone mix them (since multiple PPAs may provide different versions of the same dependencies).
As a developer, I also have too many moving targets. E.g. one piece of software that we wrote and provide requires Berkeley DB XML. DB XML is not available in most Linux distributions, and requires db(++), xqilla, and Xerces. Some distributions provide the versions of db, xqilla, and xerces that DB XML requires, there we "only" need to roll our own packages for DB XML in addition to our own software. On older distributions the dependencies are too old and newer distributions provide incompatible versions of xqilla. There we have cascading dependencies that we need to roll our own packages for. So, on modern distributions, we have to (at least) roll packages for our own software, DB XML, and xqilla. Not only is this a big hassle, package maintenance becomes as much work as software maintenance, there is a growing risk of conflicts with packages from other people's repositories. In addition to that, our users have Ubuntu, Debian, and CentOS in many different versions (Ubuntu being particularly ugly with their half-year releases) and platforms.
In contrast to that: on MacOS I just build one version on OS X 10.6 and it works for every OS X user. On Windows, I compile on any version with Visual Studio, and it works on all versions since Windows 2000. The result is that we pretty much ignore Linux, except for Ubuntu, and tell users to compile the software and some dependencies themselves on other distributions.
Given enough time, I'll probably roll a Linux version that includes all library dependencies and provide a wrapper script that sets LD_LIBRARY_PATH. But it would help tremendously if there was something standardized along the lines of an application bundle *and* a standardized ABI, so that we do not have to copy every library that the application depends on into that bundle (which in the case of the application discussed above would amount to including 50 libraries, or 76MB). Another possibility would be to statically link the application, but that has its own problems (e.g. no dlopen()).
Posted Apr 1, 2012 10:14 UTC (Sun) by khim (subscriber, #9252)
Another possibility would be to statically link the application, but that has its own problems (e.g. no dlopen()).
You can link some libraries statically and the rest dynamically. GlibC, in particular, is remarkably stable and it's easy to support older distributions with older versions of GlibC via LSB.
Something like -Wl,-Bstatic -lunstablelib1 -lunstablelib2 -Wl,-Bdynamic should do the trick.
-Wl,-Bstatic -lunstablelib1 -lunstablelib2 -Wl,-Bdynamic
Of course dlopen creates complications: if you want to use some library both from plugin and from main application (or just from two plugins) then you'll end up with two copies of library in memory! This, too, is solvable (for example you can add appropriate library to the main executable and use --export-dynamic to make it available for plugins), but yes, it's a PITA.
Yet you solve this somehow for MacOS and Windows (last time I've checked Windows had no DB XML support) thus it should be solvable for Linux, too.
The biggest problem with Linux is Q&A: if you limit yourself to LSB then you can not do a lot of things which are expected from modern program and if you use libraries outside of LSB then you immediately lose then cross-distribution compatibility and need to test your application with different versions of different distributions.
Posted Apr 1, 2012 11:50 UTC (Sun) by danieldk (guest, #27876)
Good point, thanks!
> Yet you solve this somehow for MacOS
By providing an application bundle, which is a standardized procedure and something users expect. Also, (ABI-stable) system libraries are not copied to the application bundle. So, the bundle only contains a fraction of the used libraries (Qt and DBXML).
> and Windows
Again, here we use standard libraries (VS2008 redistributable), and drop Qt/DBXML DLLs in the same directory as the executable and it works perfectly on Windows XP and up (probably also Windows 2000, but we didn't check), although the software is compiled on Windows 7.
> (last time I've checked Windows had no DB XML support)
There's Windows support for DB XML. Oracle offers pre-built DLLs, or a source archive with Visual Studio project files. We use the latter, and building the DLLs with Visual Studio 2008 is just one click.
Posted Apr 2, 2012 8:48 UTC (Mon) by nim-nim (subscriber, #34454)
Writing clever code is not everything, you need to think about what you build it on too.
Posted Mar 31, 2012 14:08 UTC (Sat) by Pawlerson (guest, #74136)
Posted Mar 31, 2012 17:09 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)
For example, one of our suppliers uses iPads for inventory management. Its camera is more than enough to scan barcodes and large input surface allows workers to view all the shipment details at once.
They've used Win6.5-based devices before that, btw.
Posted Mar 31, 2012 20:07 UTC (Sat) by Pawlerson (guest, #74136)
Posted Mar 31, 2012 21:02 UTC (Sat) by bats999 (subscriber, #70285)
It's a bit off topic because the article is about desktop Linux (whatever that is), but why do those companies choose to use iPads?
Posted Apr 2, 2012 16:00 UTC (Mon) by jedidiah (guest, #20319)
It's not the platform. It's the killer apps. People will put up with a platform they detest over that.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds