Recent Features
| |||||||||||||
The article is correctThe article is correctPosted Mar 31, 2012 9:30 UTC (Sat) by boudewijn (subscriber, #14185)In reply to: The article is correct by danieldk Parent article: Free is too expensive (Economist)
I don't understand how you can go from a factual correction -- i.e., you're anecdotal evidence was wrong so I corrected you -- to "It's never, "ok, indeed, we have too many regressions, let's fix that", but always "system Windows/OS X is at least as bad"
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.
(Log in to post comments)
The article is correct Posted Apr 1, 2012 9:54 UTC (Sun) by danieldk (guest, #27876) [Link]
> The mindset that _I_ object too, strongly, is the parrot-talk about how linux will never succeed.
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.
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()).
The article is correct Posted Apr 1, 2012 10:14 UTC (Sun) by khim (subscriber, #9252) [Link] 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 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.
The article is correct Posted Apr 1, 2012 11:50 UTC (Sun) by danieldk (guest, #27876) [Link]
> 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.
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.
http://www.oracle.com/technetwork/products/berkeleydb/dow...
The article is correct Posted Apr 2, 2012 8:48 UTC (Mon) by nim-nim (subscriber, #34454) [Link]
The only thing your post proves is that Berkeley DB XML is not a reliable foundation to build on. You can hide it under Windows or OSX, but I'm quite sure it will fail there someday too.
Writing clever code is not everything, you need to think about what you build it on too.
|
|||||||||||||