On Sun, November 21, 2004 9:23 pm, Sean Middleditch said: > You have gotten the OS installed. Congratulations. If that is the > entire reason you own a computer - to install an OS on it - then you > *really* need something else to do with your time. ;-) Well in both the cases everything I needed was actually part of the distribution. While rpm isn't perfect I find that many times finding a precompiled rpm of 3rd party applications targetted for the distro isn't hard. Installing the application is little more than a mouse click on a web page. > No, it's application installation support, which is dependent on system > ABI stability. There are two parts to my mail - system and kernel > interfaces. Don't confuse them, they are *completely* separate issues. > One affects only drivers, while the other affects only applications. I was only talking about kernel interfaces. > So far as system ABI stability, the Linux kernel does a fantastic job of > maintaining the part of it that the kernel is responsible for. The > things that do break are fringe elements that the vast majority of > applications never touch. The Linux developers aren't hurting > application developers - the glibc, GCC, and various other library > developers and packagers are. Yes, the kernel developers have done a great job protecting the end-user from arbitrary changes. > You want the hardware developers to target Linux several years before > the hardware is even released? Can I have the pipe for a few > moments? ;-) Heh, well I don't think it has to be that far in advance. With automatic system updates etc, as long as theres a reasonable lead time before product release things should all come together nicely for the end user. Even if the particular hardware isn't supported in the kernel version on the DVD platter s/he installs from. > Yes. Thank you for pointing that out. It's relevance to this > discussion is...? Didn't do a good job of relaying my point. You were saying that open-source was incidental to Linux and I was trying to show that in fact it is fundamental. Any developer working (on the kernel at least) is only doing so because the source is available. Thus everyone, whether they're gung-ho open-sourcers or not, has benefited from the open source nature of Linux. I see now that you were speaking in broader terms than just the Linux kernel and perhaps you were speaking less of open source per se and more of solid API/ABI's. > Soon? Not really. Until a stable ABI *is* enforced, it won't happen. > Linux could get a stable ABI tomorrow and supplanting would be several > years away from tomorrow, or it get could a stable ABI a decade from now > and supplanting would be several years away from *then*. > > You seem to think that hardware churn will decrease. What makes you > think that? Hardware vendors are in *no* hurry to commit corporate > suicide, trust me, and hardware stagnation would be exactly that. New > hardware needs new features or nobody has any reason to upgrade. Well, things stabalize and get used for a long time. Look how SATA is already supported in the kernel. It's hard to complain that something is wrong with this situation at least at the kernel level. > 2.0 to 3 is irrelevant - they're over a fricken decade old! Why don't > you try comparing Linux to the abicus(sp) next? ;-) Damn, you just preempted my next example ;o) > I've not had many troubles installing apps on 95, 98, 2000, ME, XP, or > 2003. There are incompatibilities sometimes, yes. There always will > be. The difference is, Windows has a far, far, far smaller percentage > of users with compatibility problems on a day-to-day basis than Linux > does. Again, I wasn't talking about the application level in my previous email. But what's wrong with the current focus on creating easy-to-use repositories for applications? Binaries can be compiled for many different distros and the proper version is selected without the end-user having to have a clue. > The differences between the six-month-apart releases of FC2 and FC3 have > caused me more compatibility headaches than upgrading between the many- > years-apart differences between Windows 98 and Windows XP. > > I'm fine with that because I'm an uber geek and for all the headaches, > I'm personally happier dealing with them than the problems I perceive in > Windows. Problems which, I'll note, no non-developer person I know > perceives. > Yes, Fedora is probably a bad example because it's not meant for the people you're fussing over anyway ;o) > Compiled source... binaries? I was trying to make the distinction between binary-only modules and binaries-compiled-from-public-source. > I'm thinking we're having a communication problem here. > > a) How do you pre-compile source that will not compile because the > developers break the API, requiring the source to be modified, without > waiting for said modifications? Presumably new versions will be released that target the new API. Until then, the old libraries are often included along with the new. For instance gtk 1.2 was including until recently even though things had moved on to version 2.0. > b) How do users use pre-compiled binaries that don't run because > developers break the ABI, requiring a different set of binaries and thus > requiring an enormous and completely unmanageable number of different > binaries to be built and exist for most users? Repositories of software are becoming more popular and provide precompiled versions for a wide variety of distros. > The changing ABI hasn't in any way been responsible for anything. The > ABI changes because the ABI wasn't designed properly in the first place, > and because people are lazy and would rather just make some small > changes to the ABI instead of introducing a new, parallel improved one. > > Take the NVIDIA driver, for example, which is a huge binary-only driver > example. The breaks it has had, with the exception of the 8k stack > issue, have been very, very minor changes in the kernel. Functions > being renamed or parameters changing. That is absolutely avoidable. > The kernel developers just don't want to. Ok, but obviously such decisions benefit the developers. And there is a long history of such decisions by kernel developers, back to ummm, the start of Linux. And Linux has still managed to become successful. Now binary-only people are complaining that their life is made more difficult than what they experience in the Windows world. Well, I think the needs of the open-source developers wins out here. They're the ones contributing the most to the community. Linux is getting in a stronger bargaining position all the time. Eventually, the market will be big enough that the hardware vendors will _have_ to play by the open-source rules if they want to compete in that segment of the market. I see no reason for the developers to cave in and make their lives more difficult for the needs of the closed-sourced hardware manufacturers who offer nothing in return but demands. Since more and more manufacturers are speaking chinese these days, it may well be that we'll see a general warming to the open-source model in general and Linux in particular. Who knows. > Now take a project like GNOME or KDE. Absolutely huge. All GPL or > LGPL. And they absolutely maintain strict API and ABI compatibility. > The only time you run into an ABI problem with those frameworks is when > the underlying OS or compiler breaks the ABI under them. > > Between fixing the kernel and the main system libraries, I'll go for the > libraries. I've seen far more problems due to application > incompatibilities than I have from hardware incompatibilities, no > question. *Both* are fixable, however, and I see no reason why they > shouldn't be. > > The people responsible just don't seem to care. I'm hoping that'll > change. The people doing the work are serving their own needs. Open source works because people contribute what _they_ personally need for themselves back to the community. Obviously it's not pure altruism that drives open source. You have to ask yourself why the developers should care? Are the problems you describe an issue for open-source developers? If they are, then you can be sure the open source developers will be solving the problem. Sean
