I don't know, maybe it's normal in some cultures, but I still can't get past people clapping after the plane lands -- if I though landing a plane was some work of art, I would never have boarded!
Apparently you've never tried to land a plane before!
Sure it isn't traditional Transformers, but it is definitely an visual spectacular. You have to remember, they had to write a movie for people that had never heard of Transformers, and somehow make it plausible to today's critical 12 year old.
Since when is "plausible" much of an issue for kids? Even today? Hell, ESPECIALLY today. The CG effects in movies today are ANYTHING but plausible. I can barely even watch them sometimes because they're just so over-the-top stupid.
The original Transformers was never very believable in the first place. Do you remember the original Transformers? Remember the scenes where Optimus Prime transforms from truck to robot and his trailer just mysteriously disappears? Or how Megatron magically shrinks to 1/10th of his original size as he morphs into a gun?
It motivates you to go for the quick and easy solution instead of the right solution. And as the gp said, in the end that will cause you to go with the "test first, lesson afterwards (if at all)"
It depends on the environment, how much pressure you're under, and how much you know going into the situation. What you say is true if you throw someone who doesn't know much into a high pressure situation with high stakes. They're going to find the easiest and quickest solution possible. No question about that. But if a person is consistently pushed only a little bit beyond their capabilities with reasonable demands and stakes, I'm confident that it can be a constructive learning experience. This is even employed in school. You're given reasonable tasks/projects to gain experience. But eventually you outgrow the the kind of experience that a school can offer. Eventually you need to go into the real world. You might start as an intern, or a junior programmer, for example, until you learn from enough experience to move on....
Even in our young industry there is a wealth of knowledge out there on how to best do things. To throw it out in the guise of "I'll experience it all myself" is just plain wasteful.
A solid education is important as a foundation. I'd never dispute that.
Experience is the worst teacher, because it's always "test first, lesson afterwards."
That just isn't true! Experience should include a lot of independent research and planning. It isn't like you're just blindly trying things to see if they work or not. The only real difference between school learning and experience based learning is that there are real things at stake when learning by experience. And that can be a great motivator.
OS design is covered at universities and the Linux kernel is often specifically examined. But they also show how other systems do things (and how they did it in the past). From what I gathered from my OS class, modern kernels are not really THAT different. I mean, they all have to do the same basic things. Once you learn the basics you should be able to just dive into the LInux kernel code and see how it works in detail.
So a series that only included bindings to a single widget set should have in the implicit expansion a completely different widget set? The "etc." stood for the perl elisp etc. (hope you can see where this is going now) bindings that I didn't list.
No, I assumed that it included Qt because, well, there's like this HUGE set of applications that use it.... that is, everything for KDE.
Let's see, GTK is the default in Fedora and Ubuntu. Mono/C# and Java basically only have GTK bindings. For a commercial entity (which you said you were) you have to pay for Qt and don't have to pay for GTK... I'm kind of assuming, again, but this doesn't seem that hard of a question to me.
I'm not the same person you originally replied to, you don't have to pay for Qt on Linux, and again, there's that whole KDE thing which makes any claim that GTK is THE toolkit standard for Linux GUI applications seem pretty ridiculous.
But at the same time, you have less chance of making money off Linux software if only because Linux users are spoiled with so much free software. It isn't like WIndows where users are accustomed to paying ~$20 for a fscking screansaver or a tool that takes screenshots.. or something trivial like that. The killer apps that Linux users might pay for are pretty complex (a personal finance app such as Quicken or MS Money, for example). Just being able to code often isn't enough. You have to know the target audience really well (and in the case of finance: tax law, accounting, etc). Not to mention that the development tools like Visual Studio just aren't there for Linux.
IMHO, Windows will only lose its dominance when cross platform development tools become as easy to use and feature rich as Visual Studio.
What is it with this slashdot obsession with "cross platform?" I don't use Linux or OS X so that I can run apps that have been dumbed down to the point where they work the same on every platform. I want applications to be as unique to the platform I chose (therefore taking advantage of its strengths) as possible. I LIKE Cooca apps, damn it! If I didn't, I probably wouldn't be using OS X. I despise Java GUI apps.
What we need are standardized protocols and file formats through which my Cocoa apps can communicate with your GNOME apps effectively.
But yes, i agree, the development tools for other OS's need to get up to par with the Microsoft tools. Apple's tools aren't bad... if you don't mind picking up Objective-C...
I would love to write software that would work on Windows, Linux, and OS X; but I work at a small development company. We are far more productive just sticking to one set of code for one platform, because there are no good languages out there that work for any platform. Or at least I have never seen any. RealBasic is the closest I have found, but it is more like going back to VB6 instead of using the newest advances in development user interfaes and other features.
IMO, there's nothing wrong with targeting specific OS. There are enough developers to go around... given the proper tools, as you mention.
I cannot wait for a language that is as cross-platform friendly as RealBasic but also as feature rich as Visual Studio. I am certain that it will happen someday, and it will certainly be a major blow to Microsoft.
If I am not mistaken,.NET allows you to utilize multiple languages in one application. If you structure your applications right (MVC), you coudl write all your business logic in, say, C++ and then just write the interface for each platform in whatever language is most appropriate.
As a user, I have absolutely no desire to see some uber-language dominate things and limit all application functionality to the lowest common denomonator among platforms. For example, I don't want my desktop app limited in some way because certain features were difficult to implement on, say, mobile devices. I prefer developers that can focus on a particular platforms and cater to it. If that means a limited selection of software, then so be it. It is much better than the alternative.
I'm sorry, what? This isn't 1995 anymore where Motif and libXaw were the main GUI toolkits. gtk+, pygtk, gtk#, SWT, etc. are shipped in every distribution
And which one of those would be the standard?:-P
I guess it is good that most developers have settled on the Big Two toolkits (GTK and Qt) but I would definitly be nice if there was just one standard.
wxWidgets is a cross-platform API that is quite unique in that it uses the native UI widgets: http://www.wxwidgets.org/ [wxwidgets.org]
Are there any examples of non-trivial wx apps that run on OSX? I'd be interesting in seeing how well they integrate. I'd be surprised if they do it well. UI APIs vary pretty widely in how they function and how the programmmers interacts with them.
As a Windows user, I'm also happy that I don't have to use some sort of "platform neutral" UI, that usually only do a compromise for limited UI functionality for all platforms instead. I've seen too much of that happen with Java and GTK apps.:-(
I wonder, does Windows really have much tht resembles a "native" UI? I know Java apps stand out like a sore thumb, but then again, so do a lot of supposedly native apps on Windows. There's MFC, but does anyone really use that directly?
As a Mac user and hobby developer, I'd much rather stick with native UI components for whatever platform I'm targetting. Sure, QT can LOOK like an OS X app, but as far as I know you miss out on a lot of integration with the OS and advanced Cocoa features. For example, you couldn't create something as simple as a statusbar item with QT, AFAIK. A better approach, IMO, is to design the application using strict MVC approach (which Apple already encourages with Interface Builder) and have a different view layer for each platform. That way there's no question about look and feel.
Though I can't say I've really seen a non-trivial QT app on OS X. Maybe it is "close enough." But given my experience with Java/SWT, I have my doubts.
Actually, it was only an 11% drop, so it would just be the "Developers developers developers developers" that they lost ground with. Don't exaggerate the data!
I'm pretty sure "secrecy" is not something that can be stolen. I can't sue (or press charges against) someone just because they found out something about me that I didn't want them to know. Breaking and entering is the only crime in this particular hypothetical case.
It doesn't sound like it was "code" at all. The TFA mentioned "fixes and support documents." Perhaps Oracle was not providing good enough support so SAP took it upon themselves to get the information they needed? Who knows.
Generally, software from 1998 runs fine on Linux. I mean, if the source hasn't been updated since then, or you can get untouched source from 1998. Just build and run. It's not as if the X Windows framework, Qt, or GTK have changed so far that legacy apps don't work.
Actually, i'm pretty sure they have changed so far that legacy apps don't work. To run that old app you're going to need the old libraries... and it gets especially hairy wen your talking about full GNOME or KDE apps. The dependencies chain on some of those apps is astounding.
I don't see how. Compile once, link many times. That's how this works.
In what universe? Libraries change. API's change.
As for 'subverting the packaging system', that doesn't seem to make any sense at all. I mean, unless you're compile/building the same apps as you're apt-getting, for example, packagers generally coexist well with compiled. Developers wouldn't have it any other way.
Perhaps I should have said it the other way around. The packaging system can subvert your compiled programs. An OS upgrade could easily remove/significantly change libraries that your custom compiled apps depend on. I've had it happen many times. You understand why packages have such strict library version dependencies, don't you?
What the hell are you on about? I dunno about Red Hat, but Debian/Ubuntu packages are usually no more than a week behind source.
Debian "no more than a week behind source?" Are you kidding me? Maybe when it first enters the system (unstable), but by the time it gets released as stable, it is months out of date. And by the time you've gotten around to updating all your servers you could be well over a year behind. I know Ubuntu is better because they do less testing, but geez, no more than a week? Yeah right.
Actually a commercial Linux program such as the copy of Wordperfect 8 I have here (built for Corel Linux which was based on Debian 2.0) will almost certainly run on a new copy of Redhat. True you might have to install libc05 and Xlib05 but that should be quite easy.
Try it.
There are lots of old Windows programs that given a chance will install an incompatible version of a DLL in \windows\system that will break the rest of Windows and even now will install different versions of DLLs to their own directories which Linux programs could just as well do.
Oh sure, that would be just awesome. Each app with its own set of libraries. Yay.
Generally, any package manager will have something similar to Slackware's checkinstall command to take the last step in building from source. Usually, a given developer needs only produce the source tarball, and the distros, if they find the program useful, will package it up themselves.
But what if I, as a developer, don't want to wait for package maintainers to pick up my package? What if I want to distribute an installable package directly from my website? Relying on distributions to pick up your package and include it in their main repository is kind of hit and miss. Especially as the software base gets larger than is reasonable for any one distribution to manage. At some point it is all going to have to decentralize.
For commercial software, yes, they have to do the final link (note: not the compile) separately in every distro; something that will take a couple of hours on a machine with VMWare and the Big Four distros.
Don't underestimate how much work can go into making a package work just right with a particular distribution. And you really should do the full compile on each as headers can be different. Not to mention default file locations and such. And what about older version of distributions? Isn't it reasonable to support those? Not everyone automatically updates every time their dist releases a new stable version.
Look, I'm not saying it is impossible ot distribute commercial software on Linux or that the fragmentation is insumountable in general. I'm just saying the fragmentation is there and it is real and it is a barrier. It isn't like OS X where you just say "build this for version 10.3 and 10.4" and, bam, you've got a single package that'll not only work on different versions of the OS but also different architectures. See the difference?
I've installed many deb but haven't had a need to make any (the software selection for ubuntu is rather extensive).
Have you tried mixing many Debian and Ubuntu packages in one system? I did once and it ended in disaster.
For RPM's you can configure scripts that can be used to dynamically change the behavior of the package to accomodate different systems (again, provided dependency versions aren't hardcoded).
You haven't explained how you can build a package that doesn't "hardcode" dependencies. Either a package requires a certain version of a library or it doesn't. There's noting you can do with a clever install script to get around this. There are, perhaps, more minor system differences that one can account for with a clever install script, but that serves to highlights the problems of fragmentation.
Short of actual binary compatibility being broken there shouldn't be a problem.
And yet there *are* problems mixing packages meant for different distributions.
I can't imagine deb lacks similar flexibility.
What flexibility?
The only time there would be a real problem with a properly crafted package (and I'm sure most debs aren't properly crafted anymore than most rpms are) would be a very old version of the distribution.
Very old? Try the last major release. What distribution are you using where you can safely mix packages from multiple versions of a distribution?
There really isn't an onus on someone distributing software for a free system to support anything but the latest stable version
That is another barrier to entry on corporate desktops.
If you are running something older than that you had best be prepared to repackage for yourself.
And every distro keeps its own repositories. And has a built-in way to install the software from them.
Exactly. They're fragmented.
Well, I've had tons of old stuff refusing to run on WinXP.
But usually it works. Windows XP is 5 years old and it is STILL pretty much the default target for all Windows software. A 5 year old Linux distribution is all but useless today.
Well, I've had tons of old stuff refusing to run on WinXP. And there is always the option of static compiling, so you have all the things you need compiled-in...
Sure, that is an option. Not a great option on the whole, but an option. I think it woudl royally suck to see developers resorting to static linking for commercial apps. It would be a huge waste of RAM. With dynamic libraries, multiple programs can share the same libraries in RAM... not just on disk.
Linux is different from Windows, in this area as well as others. However, vendors need not worry about creating packages for every single distro - that's the distro maintainers' job. They'll adapt eventually.
So you acknowledge that fragmentation in Linux is a problem that has yet to be solved?
1) Distributions get outdated fairly quickly. Package maintainers don't have time to be backporting every package to older versions of the distribution. This means you, as a user, either have to keep updating to the latest stable distribution (or potentially suffer the consequenses of going "unstable" to get what you want) or you have to compile the stuff from source yourself.
2) If you can't afford to be upgrading every single time a new major release comes out or run unstable (say you have hundreds of workstations or dozens of servers, for example), then you end up with a bunch of custom compiled apps which actually subverts that packaging system. Now you have to worry about breaking all the custom compiled stuff when you DO finally get round to upgrading the base distribution... which makes the upgrade that much more daunting.
3) Commercial/close source software. Commercial vendors can't offload the package management onto distribution maintainers. Not only do third-party vendors need to package and test their software on dozen's of different linux flavors, but they h ave to *support* it. They could, of course, just pick one or two major distributions to support, but then people who've chosen something else, for whatever reason, are left out in the cold. That is something you need to think about as a corporate user.
The problem isn't just the fragmentation. It is also a problem with how Linux software in general is distributed. You just can't expect a program from 1998 to run on your new RedHat system. You can with Windows. Say what you want about WIndows as far as quality, at least it is a stable (as in doesn't change much) target for developers. This is very important for both corporate users and developers alike.
It is in the 4 different package frontends and the dozens of different repositories with the same damn software packaged in dozens of different ways.
And in that case, is the Windows market fragmented as well? I mean, you have Win9x, Win2k, WinXP Home, WinXP Pro, WinXP 64, Win2003 Server, WinME, WinMCE, Vista Home, Vista Business, Vista Ultimate and several other flavours I have most certainly missed...
Which is probably about an order of magnitude or more smaller than the range of Linux versions given the same time period of time and scope of application. Hell, I might even put money on *2* orders of magnitude difference. Every major release of every Linux distribution since 1995... that's a lotta Linuxi!
Besides, chances are that a piece of software written (and compiled) for Windows 98 will run on Windows XP... and probably even Vista. A Linux package from a 1998 version Debian (2.0?), on the other hand, almost certanly won't run on a modern version of RedHat.
Aye, that should bog a guy down for what... a couple hours? Actually you have to package it for each backend, that means you have to put out a tarball, a deb AND an RPM. That assumes you aren't hardcoding dependency versions but I think developers are bright enough to handle it.
Sorry, but one deb does not fit every distribution.. certainly no every VERSION a distribution. A package built for Debian 4.0, for example, will most likely install not install on Debian 3.1 at all if it has any non-trivial dependencies. Nor will it necessarily install and run correctly on Ubuntu. It at least has to be tested. You simply cannot package a.deb and just assume it'll Just Work on any dpkg based system. You're being extemely naive. I can't speak for RPM based systems since I haven't used them much, but I know from vast experience that one.deb does not fit all... not even close.
The reality is, if you want to have any amount of confidence that your package will work on every Linux system out there, you usually have to package and test it for each one individually. You should also consider backporting your package to at least one previous major release of each individual distribution.
That assumes you aren't hardcoding dependency versions but I think developers are bright enough to handle it.
Where do you think dependency information comes from? If your binary is linked to a specific version of a library, there's no other option to "hardcoding" that as a dependency.
Of course if you aren't trying to gauge people with commercial software then there is no issue at all. Just release a source tarball and let the distributions compile and package the software.
Sure it is an issue. You're just offloading the issue onto distribution maintainers. The work still needs to be done. And because of the massive fragmentation in the Linux world, it is often redundant.
Slashdot Mirror
Apparently you've never tried to land a plane before!
-matthew
Since when is "plausible" much of an issue for kids? Even today? Hell, ESPECIALLY today. The CG effects in movies today are ANYTHING but plausible. I can barely even watch them sometimes because they're just so over-the-top stupid.
The original Transformers was never very believable in the first place. Do you remember the original Transformers? Remember the scenes where Optimus Prime transforms from truck to robot and his trailer just mysteriously disappears? Or how Megatron magically shrinks to 1/10th of his original size as he morphs into a gun?
-matthew
Oh yeah, that'll be a thrill. A live action movie where laser blasts are flying everywhere and yet somehow NOBODY EVER GETS HIT! Exciting.
-matthew
What would you expect from Michael Bay... for whom the film "Armageddon" is something to be proud of?
It depends on the environment, how much pressure you're under, and how much you know going into the situation. What you say is true if you throw someone who doesn't know much into a high pressure situation with high stakes. They're going to find the easiest and quickest solution possible. No question about that. But if a person is consistently pushed only a little bit beyond their capabilities with reasonable demands and stakes, I'm confident that it can be a constructive learning experience. This is even employed in school. You're given reasonable tasks/projects to gain experience. But eventually you outgrow the the kind of experience that a school can offer. Eventually you need to go into the real world. You might start as an intern, or a junior programmer, for example, until you learn from enough experience to move on....
A solid education is important as a foundation. I'd never dispute that.
-matthew
That just isn't true! Experience should include a lot of independent research and planning. It isn't like you're just blindly trying things to see if they work or not. The only real difference between school learning and experience based learning is that there are real things at stake when learning by experience. And that can be a great motivator.
-matthew
OS design is covered at universities and the Linux kernel is often specifically examined. But they also show how other systems do things (and how they did it in the past). From what I gathered from my OS class, modern kernels are not really THAT different. I mean, they all have to do the same basic things. Once you learn the basics you should be able to just dive into the LInux kernel code and see how it works in detail.
No, I assumed that it included Qt because, well, there's like this HUGE set of applications that use it.... that is, everything for KDE.
I'm not the same person you originally replied to, you don't have to pay for Qt on Linux, and again, there's that whole KDE thing which makes any claim that GTK is THE toolkit standard for Linux GUI applications seem pretty ridiculous.
-matthew
But at the same time, you have less chance of making money off Linux software if only because Linux users are spoiled with so much free software. It isn't like WIndows where users are accustomed to paying ~$20 for a fscking screansaver or a tool that takes screenshots.. or something trivial like that. The killer apps that Linux users might pay for are pretty complex (a personal finance app such as Quicken or MS Money, for example). Just being able to code often isn't enough. You have to know the target audience really well (and in the case of finance: tax law, accounting, etc). Not to mention that the development tools like Visual Studio just aren't there for Linux.
-matthew
I assumed "etc." included Qt. Don't want to forget about the KDE crowd!
So which is the standard? GTK or Qt?
-matthew
What is it with this slashdot obsession with "cross platform?" I don't use Linux or OS X so that I can run apps that have been dumbed down to the point where they work the same on every platform. I want applications to be as unique to the platform I chose (therefore taking advantage of its strengths) as possible. I LIKE Cooca apps, damn it! If I didn't, I probably wouldn't be using OS X. I despise Java GUI apps.
What we need are standardized protocols and file formats through which my Cocoa apps can communicate with your GNOME apps effectively.
But yes, i agree, the development tools for other OS's need to get up to par with the Microsoft tools. Apple's tools aren't bad... if you don't mind picking up Objective-C...
IMO, there's nothing wrong with targeting specific OS. There are enough developers to go around... given the proper tools, as you mention.
If I am not mistaken,
As a user, I have absolutely no desire to see some uber-language dominate things and limit all application functionality to the lowest common denomonator among platforms. For example, I don't want my desktop app limited in some way because certain features were difficult to implement on, say, mobile devices. I prefer developers that can focus on a particular platforms and cater to it. If that means a limited selection of software, then so be it. It is much better than the alternative.
-matthew
And which one of those would be the standard?
I guess it is good that most developers have settled on the Big Two toolkits (GTK and Qt) but I would definitly be nice if there was just one standard.
Are there any examples of non-trivial wx apps that run on OSX? I'd be interesting in seeing how well they integrate. I'd be surprised if they do it well. UI APIs vary pretty widely in how they function and how the programmmers interacts with them.
I wonder, does Windows really have much tht resembles a "native" UI? I know Java apps stand out like a sore thumb, but then again, so do a lot of supposedly native apps on Windows. There's MFC, but does anyone really use that directly?
-matthew
As a Mac user and hobby developer, I'd much rather stick with native UI components for whatever platform I'm targetting. Sure, QT can LOOK like an OS X app, but as far as I know you miss out on a lot of integration with the OS and advanced Cocoa features. For example, you couldn't create something as simple as a statusbar item with QT, AFAIK. A better approach, IMO, is to design the application using strict MVC approach (which Apple already encourages with Interface Builder) and have a different view layer for each platform. That way there's no question about look and feel.
Though I can't say I've really seen a non-trivial QT app on OS X. Maybe it is "close enough." But given my experience with Java/SWT, I have my doubts.
-matthew
Actually, it was only an 11% drop, so it would just be the "Developers developers developers developers" that they lost ground with. Don't exaggerate the data!
I'm pretty sure "secrecy" is not something that can be stolen. I can't sue (or press charges against) someone just because they found out something about me that I didn't want them to know. Breaking and entering is the only crime in this particular hypothetical case.
-matthew
It doesn't sound like it was "code" at all. The TFA mentioned "fixes and support documents." Perhaps Oracle was not providing good enough support so SAP took it upon themselves to get the information they needed? Who knows.
Actually, i'm pretty sure they have changed so far that legacy apps don't work. To run that old app you're going to need the old libraries... and it gets especially hairy wen your talking about full GNOME or KDE apps. The dependencies chain on some of those apps is astounding.
In what universe? Libraries change. API's change.
Perhaps I should have said it the other way around. The packaging system can subvert your compiled programs. An OS upgrade could easily remove/significantly change libraries that your custom compiled apps depend on. I've had it happen many times. You understand why packages have such strict library version dependencies, don't you?
Try it.
Oh sure, that would be just awesome. Each app with its own set of libraries. Yay.
-matthew
But what if I, as a developer, don't want to wait for package maintainers to pick up my package? What if I want to distribute an installable package directly from my website? Relying on distributions to pick up your package and include it in their main repository is kind of hit and miss. Especially as the software base gets larger than is reasonable for any one distribution to manage. At some point it is all going to have to decentralize.
Don't underestimate how much work can go into making a package work just right with a particular distribution. And you really should do the full compile on each as headers can be different. Not to mention default file locations and such. And what about older version of distributions? Isn't it reasonable to support those? Not everyone automatically updates every time their dist releases a new stable version.
Look, I'm not saying it is impossible ot distribute commercial software on Linux or that the fragmentation is insumountable in general. I'm just saying the fragmentation is there and it is real and it is a barrier. It isn't like OS X where you just say "build this for version 10.3 and 10.4" and, bam, you've got a single package that'll not only work on different versions of the OS but also different architectures. See the difference?
-matthew
Have you tried mixing many Debian and Ubuntu packages in one system? I did once and it ended in disaster.
You haven't explained how you can build a package that doesn't "hardcode" dependencies. Either a package requires a certain version of a library or it doesn't. There's noting you can do with a clever install script to get around this. There are, perhaps, more minor system differences that one can account for with a clever install script, but that serves to highlights the problems of fragmentation.
And yet there *are* problems mixing packages meant for different distributions.
What flexibility?
Very old? Try the last major release. What distribution are you using where you can safely mix packages from multiple versions of a distribution?
That is another barrier to entry on corporate desktops.
Exactly.
-mtthew
Exactly. They're fragmented.
But usually it works. Windows XP is 5 years old and it is STILL pretty much the default target for all Windows software. A 5 year old Linux distribution is all but useless today.
Sure, that is an option. Not a great option on the whole, but an option. I think it woudl royally suck to see developers resorting to static linking for commercial apps. It would be a huge waste of RAM. With dynamic libraries, multiple programs can share the same libraries in RAM... not just on disk.
So you acknowledge that fragmentation in Linux is a problem that has yet to be solved?
-matthew
There are a few problems with this arrangement.
1) Distributions get outdated fairly quickly. Package maintainers don't have time to be backporting every package to older versions of the distribution. This means you, as a user, either have to keep updating to the latest stable distribution (or potentially suffer the consequenses of going "unstable" to get what you want) or you have to compile the stuff from source yourself.
2) If you can't afford to be upgrading every single time a new major release comes out or run unstable (say you have hundreds of workstations or dozens of servers, for example), then you end up with a bunch of custom compiled apps which actually subverts that packaging system. Now you have to worry about breaking all the custom compiled stuff when you DO finally get round to upgrading the base distribution... which makes the upgrade that much more daunting.
3) Commercial/close source software. Commercial vendors can't offload the package management onto distribution maintainers. Not only do third-party vendors need to package and test their software on dozen's of different linux flavors, but they h ave to *support* it. They could, of course, just pick one or two major distributions to support, but then people who've chosen something else, for whatever reason, are left out in the cold. That is something you need to think about as a corporate user.
The problem isn't just the fragmentation. It is also a problem with how Linux software in general is distributed. You just can't expect a program from 1998 to run on your new RedHat system. You can with Windows. Say what you want about WIndows as far as quality, at least it is a stable (as in doesn't change much) target for developers. This is very important for both corporate users and developers alike.
-matthew
It is in the 4 different package frontends and the dozens of different repositories with the same damn software packaged in dozens of different ways.
Which is probably about an order of magnitude or more smaller than the range of Linux versions given the same time period of time and scope of application. Hell, I might even put money on *2* orders of magnitude difference. Every major release of every Linux distribution since 1995... that's a lotta Linuxi!
Besides, chances are that a piece of software written (and compiled) for Windows 98 will run on Windows XP... and probably even Vista. A Linux package from a 1998 version Debian (2.0?), on the other hand, almost certanly won't run on a modern version of RedHat.
-matthew
Sorry, but one deb does not fit every distribution.. certainly no every VERSION a distribution. A package built for Debian 4.0, for example, will most likely install not install on Debian 3.1 at all if it has any non-trivial dependencies. Nor will it necessarily install and run correctly on Ubuntu. It at least has to be tested. You simply cannot package a
The reality is, if you want to have any amount of confidence that your package will work on every Linux system out there, you usually have to package and test it for each one individually. You should also consider backporting your package to at least one previous major release of each individual distribution.
Where do you think dependency information comes from? If your binary is linked to a specific version of a library, there's no other option to "hardcoding" that as a dependency.
Sure it is an issue. You're just offloading the issue onto distribution maintainers. The work still needs to be done. And because of the massive fragmentation in the Linux world, it is often redundant.
-matthew