Slashdot Mirror
Building Applications with the Linux Standard Base
I've been involved with IBM products and documentation since the late '70s, and their documentation has traditionally come in two flavors: user's guides, and reference manuals. The former are meant to be read cover-to-cover (more or less), and the latter are meant to be looked at for specific bits of information. This book falls more to the reference manual side of the spectrum. Consequently, reading it cover-to-cover was a little dry, but the information needed to get an application certified with the Linux Standard Base (LSB) was clearly laid out.
Building Applications with the Linux Standard Base (published by IBM Press and available on your favorite bookstore sites) is laid out in five large parts: Introduction, Developing LSB Applications, Certifying for the LSB, Contributing to the LSB Project, and Using LSB Resources. Except for the first part (Introduction), the book gives specific examples, and many, many references to the opengroup.org website's sections on the LSB.
It becomes obvious as you go through the book that the Linux Standard Base is still evolving. The authors (13 core members of the LSB team) frequently allude to how the project can (and should) be extended to increase its scope and sophistication. Two chapters (Adding New Interfaces..., and Adding New Architectures...) cover (albeit skimpily) what's needed to update the specification.
Backing up for a moment, Part II (Developing LSB Applications) describes in detail (with examples) the Dos and Don'ts of coding practices. It then explains carefully how an application should be packaged for distribution (RPM), and finally wraps up with a section on porting Solaris apps to the LSB. In each chapter, step-by-step instructions are given when appropriate. Differences in filesystem hierarchy, signal handling, and program options are all laid out to help you through.
Part III goes over the LSB Certification process. Both runtime environments (distros) and applications are covered. Again, the book lays out the process in a step-by-step approach.
The last part in the book talks about the various resources available: the written spec, the test suites, and various usage guides. The chapter on using the LSB test suites shows how much thought went into making sure a successful test ensures a certifiable (in a good way) application.
All in all, Building Applications with the Linux Standard Base, has what you need if you're developing a commercial-grade Linux distribution or application. Once your product has passed the testing described inside, you can be confident that it will work on almost anything Linux. Very dry reading, but a lot of useful information packed into a slim 246 pages. I'd give it a 7 for writing style, but a 9 for content: total=8/10.
You can purchase Building Applications with the Linux Standard Base from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.
Ah, yes, standards. So many good ones to choose from.
... writing apps that work across distros is really easy - it's called Java. :)
Does anyone see how one thing is supposed to follow the other?
-Peter
There may not be that many linux-specific high-quality standards, but linux follows closely most relevant unix standards. So why not just build your applications for the Single Unix Specification and ignore any linux-specific features?
This is about the hundredth project of it's kind that I've seen since linux' infancy.
Good luck to it. I'd love see a "works with linux" stamp, and have distro choice be completely irrelevant.
It's absolutely necessary if linux is to go anywhere worth going commercially.
I don't need no instructions to know how to rock!!!!
Does this mean the "make configure" checks will be shorter, because stuff if standardized? Or where will this be visible for end-users?
Z
...programs can break on subsequent versions of linux because something has been moved or changed. Come on, guys. Maybe the reason linux isn't mainstream yet is because it's so hard to get your feet on the ground before the rug is pulled out.
An effort to make device driver standards would mean a lot more to lots of us.
That would make it easier for manufacturers to make linux supported hardware and know that it worked.
Every linux user needs linux compatible hardware, but relatively few need commercial software.
File naming protocol
------
Characters in filename names are a rare commodity, to be used wisely.
Filenames should be abbreviated to the point of obfuscating any meaning:
Why use "print" when you can use "prin," why use "prin" when you can use
"pin," why use "pin," when you can use "xb."
Standard output formatting protocol
------
When printing a table of data to standard output, there is no need to
label rows and columns. Linux users are elite professionals, they
instantly know what the endless rows and columns of hex values,
abbreviated acronyms, and various other standard and non-standard
variables represent.
In the rare occasion that a Linux user is unsure what some data
represents, he will simply view the source, if the source is not
available, he will disassemble the executable, and read the assembly code.
If you must label columns and/or rows, please
follow guidelines set out by the "File naming protocol" section.
The biggest pain in the ass I find in writing complex apps that interact with other complex apps, across different Linux distros, is the different filesystems. Where's the meta-FS-standard, where either "make" or at runtime my app can access a filesystem path under one distro's namespace (ie, on which the app was designed), and have it translated to the distro under which it will run?
"That's the nice thing about standards... there's so many to choose from!" - Anonymous PHB
--
make install -not war
Actually, each distro has its own little additions and, consequently, quirks. Writing an application to work reliably under all variations is not a slam-dunk.
IMHO, this is one great advantage that the FreeBSD project has - there are no "distros".
I think, until a Steve Jobs or Bill Gates comes out with a killer apps with a corresponding toolkit that takes over the market, we'll be stuck in the same boat.
The Kai's Semi-Updated Website Thingy
Java solves the problem of cross-platform apps at the granularity of CPU/OS-API. The JVM doesn't solve problems of different Linux distros, because they all share the same OS API. If you're running the same binary across different CPU architectures, even the same distro won't run x86 binaries on PowerPC. And if you're recompiling from source for different CPU architectures, Java doesn't do anything at runtime that gcc doesn't do at build time. Java is a solution to a more fragmented platform, like "web servers", than we have with Linux.
--
make install -not war
I'm a die-hard Java hater but I have to say that a web server is actually one of the few applications that Java can actually perform really, really well at. Java in client applications makes my skin itch, though.
Well written Java applications have little to no performance differences from native C/C++ apps.
Swing-based GUIs do have a differing look and feel than native apps; IBM's SWT GUI toolkit resolves this issue by allowing Java GUIs to appear as native ones.
I haven't experiences the problem of Java not running smoothly on various OSes. Windows, OSX, Solaris, various Linux distros - no probs.
Writing an application to work reliably under all variations is not a slam-dunk.
So it turns out that Microsoft's mutant penguin ad compaign was right all along?
For the past few years, I've been screaming about the negative effects of having so many different standards to choose from on Linux - this is why I personally use FreeBSD and OSX (well, okay, and Windows for games).
But the biggest problem (which also exists on FreeBSD), is QT. The shitty licence has caused so much damage by keeping cross-platform and commercial development off KDE (one of the most popular window managers). I know there's GTK, but I can't help think that Linux might have reached critical mass and become mainstream popular without it - GTK might not be perfect, but it is a STANDARD.
Monkey man Steve Balmer might have looked silly when he yelled it on stage, but he was right: "Developers, developers, developers." The Linux community should be bending over backwards to attract new developers into their flock, by making their passage into the fold as easy and as hassle-free as possible.
Chicken and the egg: applications for Linux, users for Linux. The Linux community can't force people to use Linux for the sake of using Linux, but they can bring applications to the platform - if they're worth using, users will follow.
Linux has approximately 15% of the server market in 2003. And it just keeps growing. That sounds pretty mainstream to me.
7 175,00.htm
http://asia.cnet.com/news/systems/0,39037054,3920
Well, the real issue with an installation API is that 99% of linux packages actually relies on some other package. For the last 1%, I don't think it should be that hard to make a simple API translater, where you'd put basic strings like "Program name", "Category" , small icon, large icon etc. etc. and translate it into distro-specific values.
But of those 1%, about 0% of the community-based programs are like that. The 1% is almost purely commercial and/or closed source apps. So why should anyone bother? For anything the volunteers do, they mostly need to integrate with the dependency system. And that can't be trivially merged.
Kjella
Live today, because you never know what tomorrow brings
"Building Applications with the Linux Standard Base" has been (apparently) also published under the GNU Free Documentation License. Here is the Online version.
> Don't assume your config file is /etc/thisapp.conf, don't /var/spool/thisapp.
/etc. I mean, I've been working around *nix for going on fourteen years now, and that was always supposed to be the place.
> assume your data is in
> Make it all configurable.
I don't know why anyone would put system-wide configuration data anywhere else but in
The only real solution to this is to make options for loading critical config data from environment, but that also seems so kludgy when compared with a proper file.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Writing an application to work reliably under all variations is not a slam-dunk.
s/a slam-dunk/possible/
Solution: Python, Perl, ANSI C, etc. i.e. don't code "for Linux" at all, just code. Of all the ports I've done, Linux is always the biggest pain in the arse, due to the joyous work of glibc, and of course Redhat's need to do everything their own way.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
Swing based GUIs do have a different look and feel: they look like crap and they feel sluggish. Even the native look and feel doesn't feel native. If you have a C++ app that responds as slow as a Java swing app, you must be using the worst C++ gui library ever.
Swing is *inherently* slow. The architecture is so reliant on delegations at various levels with pluggable look and feels that it has no chance of performing fast. Fortunately, a large number of applications do not require a super-responsive GUI. However, try building a decent Gantt chart that responds to clicks and drags like MS Project. You will find that Swing simply can't scale that well (and Project sets the bar fairly low).
Java file access is pretty damn slow, though it got a speed boost in 1.4.something. It's now at least acceptable as long as the file is text. Parsing binary data in java is a pain in the ass, and also inherently slow because it has to drop into native calls and then bounce back up into java code.
Java memory maps are fucking amazing. I can't imagine how anyone could develop something so slow and want to release it. They are a fucking joke. C and C++ memory maps are at least a hundred times faster.
What the fuck do you mean by "well written?" Do you mean "text based networking code?" Because that is the only thing that Java does extremely well. Java is incredible for text based protocols (and I think C sucks, but I probably just haven't found a good library yet).
Even on numeric stuff, Java would do well if it wasn't for the startup time. Compare a java app to a C++ app compiled with intel's compiler (no fair using g++, I they have some sort of rule that C++ must compile badly). Or compare it to gcc compiled C code. For small data files, the startup time kills the java app. For medium files, they perform about the same. For large files, Java runs out of memory and dies well before C or C++ (1.5 Gig memory limit? Why?). Oh, and also don't do a comparison on the Apple G5. The g++ optimizer is even more retarded on that (just stack allocate a 10000 by 10000 int array and set all values. Look at the awesome code that is generated).
I know how JIT compilers work. I know every JVM available for Linux and Windows. Linear sweep register allocation just doesn't compare to a good graph coloring allocator. On a register rich chip like the PPC, it shouldn't matter, but on x86 it certainly does.
Oh, and I have made simple string processing benchmarks that show Java performs better than C, it isn't that hard (hint: \0 terminated strings take linear time to check size).
> OpenOffice, or Mozilla, just unpack and install, works on all Linux distros,
> although distros do rebuild em for their specific distro you can still get
> the packages from the distributer of the app, thats how i get mozilla &
> firefox & thunderbird, and OpenOffice, RealPlayer/HelixPlayer
> too is looking much better than before...
I haven't looked at the code of these projects, but I'm assuming there's probably a lot of redundancy, shipping their own versions of libraries so as to eliminate any major problems. That's certainly one way to do it, though it probably adds considerable bloat to an install, and if there is carried over to a wide array of software, it could mean Linux becomes pretty bloated.
Looking at the Micro$oft way, with lots of memory and lots of HD space, bad and redundant coding ain't a problem. However, I work with rather trim and streamlined Linux-based routers (the kind of stuff that fits on 128mb flash cards), mail servers and proxies, and I certainly don't want each daemon to be running its own set of dependencies. I admit, in my environment, I build a lot of the binaries, and use Slackware because I find it closest to the bone (so to speak).
The world's burning. Moped Jesus spotted on I50. Details at 11.
because as good as their intentions are, it's never really going to happen.
If we pretend for one moment that Linux is all about the desktop market, the LSB is only going to have relevance to the top two or four distributions, period. The server market is more restrictive, only two distributions, most likely sharing the desktop market. Forget the embedded market totally.
NOTHING else will register, and there's no reason why it ever should.
insecurity asks the wrong question irritation gives the wrong answer
While this is true there are programs that ran on 98 that don't run on XP. If they don't make a newer version of the program you are SOL. With OSS you just recompile, which is relatively painless for small applications. Even if a simple recompile doesn't work it is still possible to modify the source to get it to work.
That way, GNOME and KDE could just be seperate shells on top of the same desktop, and they would happily run each other's apps.
That seems pointless to me. Why wouldn't you just make one shell with all the options of GNOME and KDE? It seems like after you got everything to work as one DE with different shells, you would only be one small step away from merging them completely into one.
I do think GNOME and KDE should integrate as much as they can to keep things compatible and consistent BUT it's good to have two seperate environments, especially since they seem to aim at different crowds. Also, competition is a good thing.
I'd also request a kernel driver API that unties them from the kernel--recompiling an entire kernel to support a new scanner I just bought is ridiculous. I should just be able to go online and download a special binary driver
I'm confused by this. You don't need to recompile your kernel to include a new driver. You can build modules without rebuilding the entire kernel. Also I build the madwifi-driver, which is partially proprietary and outside of the kernel, without having to recompile the kernel.
Time makes more converts than reason
The API should remain sane so that you could install something from four years ago and still have it work. I can still run Windows 3.1 and 95 applications on my XP laptop. Try running a Linux binary from two years ago.
You're FUDDing about the linux binary API, as I can install the quake 3 arena from 1999 (which I originally ran on redhat 5.2) on my suse 9.2 and it runs perfectly.
As to your windows backwards compatibility, you lose points for dishonesty. I know of quite a few w95/w98 apps that simply crash and burn on 2k/xp - and you claim all windows 3.1 apps run fine on xp?
I call bullshit.
I don't know why anyone would put system-wide configuration data anywhere else but in
Yah, but that's not what he's alluding to. What about
Hence, make it all configurable. Then you don't have to worry.
It's not only bloat, it's also a security risk. You THINK you updated that imagelib with all those backdoors, in all programs that use it, I mean every single one of it?
Actually, the rule is that unlike the Intel compiler, G++ is cross-platform. Unfortunately, the IA32 architecture is a bitch to compile for.
Most modern compilers are designed for modern architectures, and the GCC suite is no exception. Unlike a modern architecture, the IA32 has effectively zero integer registers and precisely zero floating-point registers (that you can actually treat as registers, anyway). Basically, the IA32 is the exception to every rule.
Mind you, the IA64 is even worse in this respect...
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
The differences between Linux distros are what make Linux a vibrant community and drive innovation. I hope the LSB project fails miserably to remove those differences.
-73, de n1ywb
www.n1ywb.com
What about the gnu java compiler that produces binary code from java?
Swing-based GUIs do have a differing look and feel than native apps; IBM's SWT GUI toolkit resolves this issue by allowing Java GUIs to appear as native ones.
.
Yeah, but though SWT on any platform, and GTK+ on Win32 with a certain theme may _look_ like the native widgets, the problem is that they're not
Besides not "feeling" the same, some things that affect native widgets won't work with those since they're basically just bitmaps. For example, themes (think windowblinds, or XP themes engine on Win32; custom theme engines on GTK or QT). Screen readers, unusual font sizes. All of these don't interact correctly.
I've even run into copy/paste problems with swing before -- some third part programs don't interact well.
Right now you can install and uninstall binary software on Linux (pretty much any Linux) with no significant problems if that software has been packaged with the Loki Installer.
Somewhere around here I have Loki's Myth II for Linux CD from some time last century, and I'd bet that if I tried to install that now it would work fine, and if it didn't work it would be because I don't have the 5 year old C library compatibility package installed. Note that I'm not the least bit worried about what distro I'm running - even though I'm not running Red Hat, or even an RPM based distro.
RealPlayer 10 is another example of packaged binary Linux software that Just Works(tm).
In conclusion, as long as the software was packaged for the current version of libc, it should work fine, libc has only changed twice since I started using Linux back with Kernel 2.0, and most if not all major distros have compatibility packages to solve even that issue.
If you want to complain about the Libc issue, try running the following programs under Windows XP SP 2:
Warcraft I
Star Wars: Dark Forces
Adobe Live Motion 1
-- The act of censorship is always worse than whatever is being censored. Always.
That is so fucking insightful.
ROMANES EUNT DOMUS
Your argument isn't valid. If the cross-platform capability was what was hindering the C++ code optimization, then the same argument should apply to their C compiler. gcc generates very good optimized C code. The reason the optimizer is bad is because of the development history of g++. They evolved the compiler to support more and more of the standard (which is a good thing). In the process, however, more and more available optimizations were lost (which is a bad thing). It's that the available manpower is being spent on getting the C++ compiler standards compliant instead of making it generate fast code. I have no doubt that when the standards compliance is done that the optimizations will kick ass.
Oh, and I am the grandparent poster. I actually use g++ despite the bad code generation because it is the only compiler that actually compiles some of my C++ code correctly (although when the intel compiler does compile it, I use that -- yay test cases). Besides, it's still faster than my equivalent java code. I didn't mean to offend any gcc fans. It's just still fairly young in its development.
After reading dumb comment after dumb comment, i do wonder if linux has a bright future. But i can always hope that when linux will be one big standard windows distro that some bright chap will have forked a good non standardized rebel version that wont succome to all the problems that arise with Standardizing things. Also it seems to me that microsoft has driven advancement for quite a while now with their resource demanding software. And i still see people bitching about Java not being as fast as binaries, why not skip the whole Compilation process and have dynamically compiled source that is compiled at runtime that way you take the worries for dependancies from the developers hands and put it in the hands of the compiler. As a developer i will install the necesary tools to cary out a certain functino of my software, but then i have to worry that it might not work on machines that dont have this or hardware that is less then that etc. Why the hell not just distribute the source code and have the compiler decide that on the spot ? I need this library, then go get it from its location online and run the damn application. Yes its slow but that can be a good thing.
That's really not an even comparison. Binary versions of the GIMP aren't designed to run on any distro but the one it was compiled for. Quake 3, like Flash or Photoshop on Windows, are designed to run on a variety of OS versions. Linux could easily have Windows-like binary compatibility. Apps, like Windows apps, would have to be distributed with all their dependencies. But given that 99% of Linux software is open source, why deal with the bloat that comes along with such a model, when you can simply download packages targetted for your distribution?
A deep unwavering belief is a sure sign you're missing something...
It's a poor craftsman who blames his tools.
... it's best to pick a language optimized for the task at hand. Or even parts of it: I've worked on many applications where I would use, say, C or assembler for time-critical or compute-bound modules, and something easier to work with for the GUI and file-management layers.
Absolutely true, and I can't tell you how many times I've heard otherwise-talented programmers blame their development environment for performance or stability issues. My attitude is usually something on the order of "Stop your bitching, get off your ass and deal with it."
Conversely though, it is a good craftsman who picks the right tool for the job. Most languages can, to some degree, accomplish most tasks, just not necessarily well
What irritates me are programmers that learn a couple of languages and insist upon using them for everything, whether it's a good design choice or not.
The higher the technology, the sharper that two-edged sword.
They're both major games that were released targetting computers with Windows on them. Expecting these to work on the current version of Windows is *exactly* as appropriate as expecting software from the same period for Linux to run on a current version of Linux - and with Linux you can get that stuff to run usually just by installing a compatibility package.
If Live Motion 1 works on XP SP2 it's through some sort of downloadable fix/hotpatch - equivilent in annoyance to installing an "old libc compatibility package".
-- The act of censorship is always worse than whatever is being censored. Always.
I was under the impression that the linux kernel having all the drivers tied in was actually a conscious option, based on the idea that they wouldn't have to keep support for obsolete APIs, thus preventing some of the flaky windows drivers we get. Plus, you don't actually HAVE to recompile the kernel. Just compile it once with EVERYTHING as modules. Then modprobe for what you want :) (or perhaps there is some intrinsic limitation to this that I'm not aware of?)
AFAIK, java is no longer based on bytecodes, but rather JIT compilation. This means it CAN and WILL be slow as molasses in the winter when first starting up, but will probably be just as fast as your usual C program when running. The garbage collection bit could slow it down, but I don't think its impact is tremendows.
Give it a shot.
I guarantee you money it wont work.
I gave up trying to run quak3.
Libc changes, api changes, script changes, binary incompatiblities persist. I can run old Windows apps but one program compiled even for the same Linux distro like redhat wont work in later versions.
Its lightyears behind Windows, Solaris, and MacOSX>
http://saveie6.com/
Your running kernel version 1 and the drivers in kernel version 1.2 and version 1.2 has some API changes that the driver uses.
Kernel 1.2 also has a very new VM that causes no amount of grief (as do the new changes in the API) so it's not an option to just download the driver and compile.
You could probably hack the driver to work, but then it would could be buggy and it would be hard to benefit from other bug fixes etc...
The drivers and the kernel need to be seperated for the good of Linux, what happens in a few years when we've got twice the number of drivers to maintain and how can you expect a comercial(one that makes money!) opertion to try and hit such a moving target.
thank God the internet isn't a human right.
XP even provided a compatibility mode for older applications. Which was so generous of them. And efficient as well. I'd say under 20% of all apps/games I've tried to run under compatibility ever ran.
No that's definately not the idea behind LSB. I attended a Debian conference a couple years ago where they were talking about it, and to be LSB compliant, a system just has to meet certain baseline criteria and provide some utilities. Essentially, it has to be able to install and uninstall a LSB rpm format package. How this is accomplished is up to the distro to implement. I think Debian has an LSB package which installs some libs and stuff here and there and makes sure you have rpm installed. LSB packages will never supercede debs and Debian doesn't plan on leaving dpkg and apt for the main package management; however, if you install the LSB compatibility metapackage then you have the ability to also use these type of packages. If you ever want to see high end apps like CAD and drafting programs available for Linux, then something like LSB is needed to ensure that the vendor can provide one binary for all compliant Linux systems and it will just work. Thats all LSB is supposed to be.
Clickety Click
Le entiendo. Quién cuida si usted no puede mecanografar la palabra "slow" en su SW de la traducción? Quién cuida lo que usted piensa sobre arquitecturas del microprocesador? Especialmente quando usted es incorrecto?
--
make install -not war
### I don't know why anyone would put system-wide configuration data anywhere else but in /etc. I mean,
Because you might want to have two different versions or two different instances of the same programm and don't want them to share the same config file. Everytime that happens you basically have two choices a) throw the binary away and recompile everything from source and b) use a hex-editor and fix the path to the config and the rest, both of course work, however neither of one that I would consider a 'good solution'.
The throuble is, where do you want to configure it? If you have no /etc/thisapp.conf you are already in deep throuble. The throuble is really that Linux or Unix in general doesn't provide much of a standard way to configure a binary, stucking stuff into /etc/ and crossing the fingers that you don't run into a version conflict with another version of the same software isn't exactly a clean solution.
/proc/self/exe might help here, since that tells you at least the location of your binary, however that is something that I found more or less by luck, not really sure if thats save to use for that purpose.
So far there isn't even a standard way to locate the data that the binary needs, so most app still hardcode that.
### Even if a simple recompile doesn't work it is still possible to modify the source to get it to work.
/opt/lsb-gnome-1.4 and a /opt/lsb-gnome-2.0 installed in parallel without much problem, however that wasn't available back then and still isn't, but at least the direction in which LSB goes is correct.
Yes, there is always a way to get it work somehow, however that is often WAY bejoint that what a normal user can do. Compiling something like a older version of Gnome or so is a hell of a task, since all its dependencies have moved on two and you have to do some good digging in the historie books and what you need and where you can still get it. Doesn't sound usefull? Well, thats exactly what I would have liked todo a few years ago when Gnome2 came out and the distro switched to that, wanted to get my Gnome1.4 back, however there was no way getting that back without a heapload of manual work. When LSB would have been more widespread back then it wouldn't have been a problem in the first place, since I just could have
True, but if there is a demand someone will surely modify the source and package it up for you. At least this is possible.
Time makes more converts than reason
Actually, each distro has its own little additions and, consequently, quirks.
GNU's not UNIX. I get a bit of a laugh out of that.
-- "Makes Little Debbie look like a pile of puke!" - Moe Szyslak
Try running a Linux binary from two years ago.
I run Debian stable, you insensitive clod!
Your response is troll/flamebait at best, "clueless" at worst.
.NET if you have half a clue of what you're doing.
Java GUI apps... go ahead, criticize java for not performing well in the context of a cross platform GUI app. All it needs to do is properly re-create an acceptable interface on every possible native GUI library. How hard can that possibly be?
It's not like half the native GTK+ or QT apps aren't just as unusable, or that no serious GUI apps are written in Java anyways. You could write a GUI app with PHP and it's QT bindings, but why bother? Red herrings do not a point make.
On the other hand, server side... the only thing that's slow about java is your understanding of it's progress since, well, 1997 or so, when you're comment may have been valid. Server-side java performance is about as good as PHP or
That said, I can write a pretty poor, slow-ass PHP app just as easily. So what's the point?
As for Java not running well on all platforms... our company (and most others) have server side apps running on Debian, Solaris, OS X and Windows without issue.
So I'd suggest that, in your case, problems likely exist between chair and keyboard.
bash-3.00$ uname -a
SunOS panda 5.10 Generic sun4u sparc SUNW,Ultra-2
Qt is licensed under the GPL, with the option of a commercial license for a fee.
It's not LGPL, sure. That means that commerical developers must buy a license from TrollTech or make the source to their application availible under the GPL. Not ideal for developers, but TrollTech are not a charity, and in my view they're rather generous to permit Qt to be used under the GPL (yes, it's just good business, but still...).
I'd like Qt under the LGPL - or heck, the BSD license - too, but I don't see a viable way to keep Trolltech in business. I can't see any reason why they would release it under such a license, and think it'd be pretty dumb to ask them to. Additionally, TrollTech do the vast majority of the development on Qt, and I'd like it to continue improving so I can have more introspection and meta-object goodness in C++.
Commercial developers have two perfectly good options - use Gtk, or buy a Qt license. I don't see that as a big deal. Remember that the "competition" is hardly in the business of offering cross platform GUI toolkits.
It is the byte-code that gets interpreted or JIT-compiled. And I don't really see any reason to argue performance with Java as long as there are other problems (like compatibility between versions) that prevent use of Java to create interoperable apps that work in a year or more with the JRE that is current then (so other apps which need the new version can run in parallel)
Linux is not Windows
Or you could just use the commandline options for another config file path (usually -c)
Linux is not Windows
Of course, this is all because the new IO libraries are very thin wrappers around native routines.
This is, of course, the point of Java.
You say it like it's just Java "cheating" somehow.
bash-3.00$ uname -a
SunOS panda 5.10 Generic sun4u sparc SUNW,Ultra-2
Quake3 works just fine, right now, on Fedora 3 for x86-64. As does Return to Castle Wolfenstein based on the same engine. I played both of them yesterday. The only thing one needs to do is use the "setarch" program to trick the installer script into thinking the architecture is i386 so it won't get angry.
Both games come with their own C libraries and are, for all intents and purposes, statically compiled. That being the case, there's no reason why they won't run for years and years to come.
Ita erat quando hic adveni.
And what does Windows provide?
The Registry? A bloated filesystem-like addon with lots and lots of keys of which nobody knows the purpose AND suffering from the same problems you describe (problems with two parallel versions of the same app and no clue where the config info for any given app is located if you are not the author).
Perhaps you should propose a solution for this (without a global unique-name-giving authority)
Linux is not Windows
...is lack of coherent marketing. Competitors are very careful to frame any discussion with technical details and stresing that there are many different versions. The key to selling Linux to people who make decisions is to take a step back and focus on the high-level. Explain just how cheap it is and just how rock-solid and secure it is. Don't let the MS advocate in the room bait you into a debate about the finer technical points. I've got a bunch of stuff at www.softwareobjectz.com that may help to frame the discussion better. www.softwareobjectz.com
http://www.softwareobjectz.com
Yep, leads however to several uglynesses. Since command-line options are pretty dynamic, one needs to write them down somewhere, which in turn leads than to Wrapper scripts, which then require renaming of the real binary (foo -> foo.real), which in turn makes 'ps aux', 'gdb', 'killall' and a bunch of other things more difficult to use, since you always have to lookup the real name of the binary first. Overall probally the best solution today, however still not really optimal.
/proc/self/exe Symlinks and if those EAs are relative they might even survive basic moving around in the filesystem. However EAs are as far as I know still not available on all major filesystems or only with patches, so it wouldn't work much good today.
What I would like would be EA (extended records) on the binary file itself which carry the necesarry start-up config filename, the access to the records could go via the
### And what does Windows provide?
Windows doesn't spread an installed application all over the filesystem but keeps them in their local directory. That said, the registry still contains a whole bunch of redundant information which makes moving applications difficult. However moving basic application in Windows around is pretty doable. Last not least, this in not only about moving them, but installing them in a different location in the first place. Say installing a RPM/DEB in the users homedir, on Windows that is no problem, since basically all applications can be installed wherever you like, under Linux its basically impossible with a binary (hex-editor tricks asside).
make modules modules_install
Now was that really that hard?
Not to mention getting it installed. I just installed Epson scanner into FC2 and it was huge pain. The reason is 99% because Linux USB (hotplug) "just sucks".
Are you using udev? It's been a breeze for me. My usb key shows up as a consisten device node now.
Not to mention that Mr. Torvalds insist on non-binary drivers (insane).
You might want to take a look at the GPL.
Time makes more converts than reason