The main problem is that packages have to rebuilt for each version of each distro (broadly speaking). Distros like Debian and Gentoo blur this somewhat as for most of their users, they don't really have versions, just a constant stream of new packages.
This leads to rather frustrating scalability problems - if you upgrade from RH7.3 to RH8, or even 9, you have to find new packages, the old ones are, well, risky. As Redhat (and many other distros) rev approximately every 6 months, and there's a bit of lead in time before all the packages are rebuilt, that means often there isn't any package for your distro.
Combined with the fact that apt and RPM don't really deal with decentralisation all that well (witness the epoch mess between FreshRPMs and Fedora), both being originally designed on the assumption of central organisation, and you have dependancy hell.
In fact, it has little to do with shared libraries, although that's the most common "type" of dependancy. Generally packages depend on implementations of interfaces, the difficulty being how do you manage those interfaces, and how do you manage the packages that implement them (bearing in mind that interfaces can change but remain backwards compatable, some packages are parallel installable, some are not, multiple versions of everything etc). The rag bag of conflicting metadata sets we have today is only one of the problems though.
Anyway, I think people get misled by MacOS drag and drop installs. When OS X first came out, my friend ranted and raved about how fab appfolders were, and how he never had to use installers. About a year later, I observed him using an installer, and asked him why it didn't use an appfolder. He explained, usual reasons, needed authentication, placed files outside the appfolder blah blah. Does that happen often? Well, most apps come as appfolders. Last time I asked, "most" had turned into "some". DOS/Windows used to use app directories as well, and moved away from it to an installer based model. Now MacOS seems to be treading in its footsteps. And anyway, apt-get type functionality is far easier even than dragging appfolders around. Nothing really beats it in my experience.
Fruity Loops sort of works in WineHQ, I was debugging it a while ago (well, the first window:p) but not good enough for real usage. Cubase won't ever work in Wine as it requires the Windows equivalent of kernel modules, which Wine cannot do.
Last thing I heard the NPTL support code wasn't yet in CVS, you have to buy it from them. It will get there eventually, but it's tied up with their copy protection proprietary stuff.
It never will, because there will always be a lag between new APIs being introduced and Wine implementing them. But OK. Let's suppose the impossible happens.
Now, why in the world would they suddenly throw away all the code, tools, and experience they have on their current platform to grab some tiny extra percentage by learning, developing for, and testing on a new platform?
Good question. A few possible answers:
They want better integration. There are limits to how well Wine can integrate with Linux. It does a hell of a lot better than, well, any other emulation I've seen, but it's constricted by the limits of the Win32 API. For instance, we can do integration with the window managers kill facility, which pops up an "this app has frozen" message like on Windows, but we can't do startup notification. There's no way to extract that info from Win32 apps.
Better reliability. Win32 is huge, complex and mostly the product of too much acid usage. The number of things that can go wrong is large, the native APIs are normally easier to work with, and more complete.
No dependancy on Wine. For many people, that's good enough.
After all they can happily tell those Linux people "You're unsupported. But try WineX!" When it fails, they simply say "You're unsupported!" They already have your money, after all, and it's your own fault for trying it on an unsupported platform.
If you're unsupported, you're unsupported and you presumably know that when you buy the game. It has nothing to do with the jump table offsets or data structures in use. Smart companies will cater to their customers even when they're using emulation, stupid companies will make up excuses to get out of their obligations.
et's be honest: Isn't WineX just a bandage for all those Linux users (former Windows users) that can't give up Windows games?
What has the fact that they are Windows games got anything to do with it? If Linux users want to play games, let them. Far more important to code in general is how free it is, rather than what APIs it uses.
Look at Bleemcast (PSX emulator for Sega Dreamcast). It emulated the original games on a different platform, even with graphical enhancements, but it didn't convince anyone who already had a PSX to jump on the Dreamcast...it just made already-committed Dreamcast owners happier
This is the same old OS/2 argument. The dreamcast died for LOTS of reasons, having emulation wasn't the major factor, if it was a factor at all.
You have to take the intersections, there may be 700k iPods, but you need to eliminate the people who don't have Macs, the people who don't have/want the latest version of MacOS X, the people who aren't aware of this service and the people who would rather get their kicks off the P2P networks rather than pay Apple for it.
Ogg isn't screwed, far from it. In the long term, I suspect it'll be what we all use (I'm talking 10 years maybe here). Historically open systems have won out time and time again over sometimes arguably superior proprietary solutions. GIF vs PNG is a good example given above, the only reason PNG hasn't wiped GIF out is because IE can't do proper transparency without stupid hacks (basically the IE team are lazy asses), and from what we've seen it seems Ogg is keeping pace with the far better funded alternatives easily. Sure, it'll take time, but in a few years AAC will be as relevant to audio as Intel Indeo is to video today.
Re:Anyone seen real specs for Apple's format?
on
AAC vs. OGG vs. MP3
·
· Score: 1
Being able to play something using QuickTime isn't the same as decoding it unfortunately.
I'm not sure how much of a blind eye they'll turn, but Windows for instance actually decrypts the audio in the kernel to try and prevent people writing fake audio drivers that dump straight to hard disk.
Sure, today the only way to copy things is to burn to CD and back again. Tomorrow, there'll be a hacky way to do it direct, and the day after there'll be a GUI for it. How many people will say no to their friends? Boom, network effect. That's what the industry is scared of.
Get a clue already. Apple went with AAC because it's great quality, supports the (fairly mild and necessary to get the RIAA onboard) DRM restrictions for the service, and is a subset of the excellent MPEG4 video codec.
The first one seems rather dubious, sure, it might be good enough, but "great" implies better than the rest. The second seems irrelevant, they could have easily built a DRM/encrypted wrapper around Ogg (though I'm sure that'd have gone down like a ton of bricks here;) and the third seems equally irrelevant, unless Apple actually enjoy paying extra licensing fees.
I rather suspect AAC won out because, as is often the way, the commercial codecs have people with large wallets in the right places with a vested interest in seeing them succeed, while Ogg only has Monty. Plus after having gone to all that trouble to try and make MPEG4 slightly less unfree, they probably wanted to get their monies worth.
When you started, you put a lot of effort into Wine, sponsoring things like WineConf. That didn't work out, but Wine improves constantly, as the latest releases of CrossOver and WineX show. Do you think you'll ever return to it someday, or are you disillusioned with the whole thing?
What you call "cooperative multiprogramming" is actually called "interrupt time." All documentation of which I'm aware refers to it as "interrupt time." No euphemism required.
The confusion may come from the same on Win3.1 being called co-operative multitasking, due to the need for apps to relinquish control manually.
The main problem is that the book is full of lots of very minor problems. Yeah, so the cryptic command names are confusing at first, BUT:
a) They are easier to type
b) They have lots of inertia
There are lots of things we could change, but you have to weigh the improvements against the cost. And really, the improvements for a lot of these things would be mostly cosmetic, and the cost in terms of compatability breaks would be high. So we still use "etc" for config files, even though nobody seems to actually know why it's called that, just because there's a whole load of material out there that relies on that fact.
I'm not really convinced there's a big case against UNIX as a whole in that book. Yeah, it's full of archaic quirks due more to history than anything else, but some of the more braindead stuff is fixed (try killing files with tar cf foo, it won't work on Linux). The criticisims of X resources and xauth are valid, but pretty much anything that's been around for a long time has warts. At some point I suspect X authentication will be cleaned up - in fact these days SSH has it integrated anyway, I never needed to play with xauth.
So, while the criticisms may be valid in many respects, very few are large enough really to be worth fixing. I'm sure you could do something much better than UNIX, but then you have to start from scratch with skills, documentation and so on when all you've gained is satisfying an engineers desire for "cleanness", something that rarely if ever impacts users seriously these days.
For Quicktime, try GStreamer. More advanced than, well, pretty much anything.
For OpenDoc, try KParts or Bonobo (i think opendoc was nicer, but arguably KParts or Bonobo are in wider usage).
Quartz - there isn't really one, and for good reason. It kind of sucks. There were efforts to add Display Postscript type capabilities to X, but they were abandoned after it was realised that the approach was flawed. Xr/Xc seem a better way to achieve the same thing.
I'm not sold on the innovation thing. Innovation is not good per se, you have to balance it with all the other factors. If Linux was a super-whizzy ultra-innovative research OS, not only would it have far fewer apps and users, but Ballmer would just be slamming it for not having compatability with anything. You can't win with guys like this.
Anyway, it was decided right back at the start that usefullness was more important than innovation. That doesn't exclude innovation, but people make a really big deal out of these accusations that they probably shouldn't do.
I really, honestly, haven't seen much innovation from Linux.
Well, that HTTP.SYS thing sounds quite similar to the TUX in kernel web server switch. Innovation? Not sure. Check out Slicker. UI research. Is the GNOME2 "less is more" philosophy innovative? ReiserFS is really doing some cool things with filing systems.
The problem with "innovation" is that it's so badly defined. Everybody operates under a different definition. So, I don't see much coming out of the computing industry as a whole that I'd class as innovative right now. There are things. Just not many.
I don't think you can make arguments about whether open source is more innovative than proprietary software. I believe innovation is a function of the individual. Sure, there are innovative environments, but for every argument I've seen saying "open source isn't innovative" there are plenty of good counter arguments.
For instance, I would disagree totally with the idea that paid employees are more innovative by definition. The corporate environment is focussed on increasing the value of the company for shareholders - if you have no need to justify profit, you can work on all kinds of things that traditionally probably wouldn't get the green light, and who cares if you fail?
There are also examples of MS innovation, I mean, really innovative stuff like some of the IE bookmarking enhancements that MSR produced a few years ago, that simply never got into the main product. The researchers attitude was, "well we send the product team a report, but we don't know if they read them or not" which stunned me. At least with open source, if somebody doesn't want to implement your innovation, you can fork.
So I haven't seen any convincing arguments that open source isn't innovative. The majority of open source probably isn't, but then the majority of stuff is not innovative, that's part of what makes innovation special and prized.
Free software may be fine and dandy, but some of us don't actually mind *paying* for software if said software does the job well. Shocking, isn't it?
I feel you should read the writings of Stallman, in particular the article about the early days of the GNU project. In particular, I'd note that Stallman made a living for many years by selling tapes with emacs on for $150 - it's free software, but people paid for it.
The issue of free software has very little to do with "cheapness", and everything to do with long term benefits for all.
I know, you're trying to change that, but face it: Commercial software is not inherently evil, Proprietary software is not evil, RMS be damned.
This is a fairly common mistake on Slashdot - stating your position does not make it valid. Stallman has quite eloquently argued that for various social, economic and technical reasons it's better for software to be free than proprietary. He's never said proprietary software is "evil", and apart from some excitable ACs on/. I have yet to see anybody else claim that either.
So, if you want to be taken seriously, you're going to have to:
a) Respond to Stallmans arguments.
b) Provide some of your own showing that proprietary software is a good thing.
Quick tip about the second one - saying "that's how it's always worked" is not an argument.
Your last paragraph confuses me - it appears to imply that free software is always lacking in features to proprietary software. No matter how much I'm willing to pay, I'm unable to get a version of Internet Explorer that has tabs built in, or that has non-lame JavaScript error reporting without crash-prone extra debuggers, which in fact is currently frustrating my work no end (which is why I'm reading slashdot:). Convenience is an entirely separate issue.
And in fact in this case it appears from some of the comments that GNUcash is significantly more stable and integrated on Linux at any rate than MoneyDance. I don't know enough to compare features.
To be more accurate, prelinking allocates each library a unique location in virtual address space and then stores the precalculated GOT (or is it the PLT) in a new section in the binary. That means you only need to do a few links, instead of a lot (due to the ELF fixup semantics, sometimes you get conflicts which must always be linked at runtime).
Re:Torvalds muddying discussion with PERSONAL stuf
on
Linus on DRM
·
· Score: 1
Who gives a rat's ass what RMS says about your ideals. The question is what are your ideals? The continued existence of GNU/Linux above all other things?
Indeed. This is probably the most interesting question of all. Linus makes a big thing of being apolitical, of caring only about the code. That's fine when events are rosy. If something unexpected were to happen, what would he do? Without ideals to guide him, how can we predict what he might do?
And if we cannot predict what he might do, if there is no way we can say "Don't worry, Linus will stand up for this", why is he the leader?
OTOH, I don't think that Stallman should be trying to push his ideology on Linus any more than Linus should be trying to do so to Stallman. The difference is that Stallman tries to do exactly that with Linus, and Linus doesn't do so to Stallman.
Stallman doesn't "push" his ideology onto Linus anymore than Linus pushes political indifference onto Stallman. RMS argues forcefully for certain positions, and you know, many others join in the merry little flamewars, including Linus.
The fact that RMS appears more forceful is simply because he has strong opinions, whereas all too often Linus' opinion seems to be "only the code matters" where that clearly is not true - if everybody used the best tool for the job Linux simply would not exist. I don't think anybody could succesfully argue that no idealism has motivated any Linux development work.
Well, if you compile it using SDL in Linux you have a binary that links against glibc and SDL, and uses ELF as its binary format. Quite a few forms of UNIX can do that (well, not sure about the glibc part, but libc interfaces are mostly standardised). You'd need to somehow hack symbol versioning off, but that's doable.
It should be source code compatible with other platforms though. So the binary may be Linux native, but the program itself really is not.
You can dismiss my arguments as whatever you like, I don't really care. They're my opinions, and last I checked, everyone was entitled to their own.
Opinions on their own, while acceptable, are generally worthless, especially when you try and convince others using them. You stated many things as fact "Wine hurts Linux", "Linux users are too cheap" etc, and if you're not going to back them up with credible arguments we might as well ignore you - what else can we do?
Re:Right tool for the job
on
Linus on DRM
·
· Score: 5, Insightful
Slow down there.
RMS thinks in a different way to most of us. When he chooses a tool, he wants one that conforms to his ideals because he isn't just thinking about the next 5 minutes, he isn't interested in just solving this problem and moving on. He thinks a long way ahead.
So when you offer him a proprietary piece of software, he won't use it, even if it's more convenient than what he already has. He believes that in the long term, it's the wrong tool for the job, because he takes into account things that to most people are entirely ethereal - things like what kind of society he wants to live in, the long term maintainability of the software, lack of vendor lock in and so on.
I see way too many people slamming RMS for not being pragmatic enough. I think in reality he is very pragmatic, but with a different timeframe for his concerns to most people, leading them to view him as a "nutjob" or having "alien" thinking.
As in desktop neutral. IMO "Karma Sucks" is wrong, GTK2 is indeed neutral - it has no dependancies on any of the GNOME libraries, it's used in a lot of non-gnome software (gaim, xmms, gimp etc). The fact that GTK is easier to configure in GNOME than KDE is more to do with where the respective developers priorities lie than anything else, KDE could easily write an xsettings front end, but so far have not.
As just one example, three key pieces of DirectPlay (the pieces which cover the specifics of game connection and negotiation!) are patented. Don't believe me? Go do a patent search...
Luckily quite a few top name game developers refuse to use DirectPlay as it requires Windows servers and too many game servers run on Linux these days to ignore.
There could be problems with patents yes, but that's an issue for the whole of Linux (mp3, ntfs etc) not just Wine. And as SDL is simply DirectX done again, patents would cover similar Linux technologies also.
Slashdot Mirror
This leads to rather frustrating scalability problems - if you upgrade from RH7.3 to RH8, or even 9, you have to find new packages, the old ones are, well, risky. As Redhat (and many other distros) rev approximately every 6 months, and there's a bit of lead in time before all the packages are rebuilt, that means often there isn't any package for your distro.
Combined with the fact that apt and RPM don't really deal with decentralisation all that well (witness the epoch mess between FreshRPMs and Fedora), both being originally designed on the assumption of central organisation, and you have dependancy hell.
In fact, it has little to do with shared libraries, although that's the most common "type" of dependancy. Generally packages depend on implementations of interfaces, the difficulty being how do you manage those interfaces, and how do you manage the packages that implement them (bearing in mind that interfaces can change but remain backwards compatable, some packages are parallel installable, some are not, multiple versions of everything etc). The rag bag of conflicting metadata sets we have today is only one of the problems though.
Anyway, I think people get misled by MacOS drag and drop installs. When OS X first came out, my friend ranted and raved about how fab appfolders were, and how he never had to use installers. About a year later, I observed him using an installer, and asked him why it didn't use an appfolder. He explained, usual reasons, needed authentication, placed files outside the appfolder blah blah. Does that happen often? Well, most apps come as appfolders. Last time I asked, "most" had turned into "some". DOS/Windows used to use app directories as well, and moved away from it to an installer based model. Now MacOS seems to be treading in its footsteps. And anyway, apt-get type functionality is far easier even than dragging appfolders around. Nothing really beats it in my experience.
I think perhaps you don't understand. Wine doesn't need Windows. You can buy 3 good, modern games for the price of Windows alone.
Fruity Loops sort of works in WineHQ, I was debugging it a while ago (well, the first window :p) but not good enough for real usage. Cubase won't ever work in Wine as it requires the Windows equivalent of kernel modules, which Wine cannot do.
Last thing I heard the NPTL support code wasn't yet in CVS, you have to buy it from them. It will get there eventually, but it's tied up with their copy protection proprietary stuff.
It never will, because there will always be a lag between new APIs being introduced and Wine implementing them. But OK. Let's suppose the impossible happens.
Now, why in the world would they suddenly throw away all the code, tools, and experience they have on their current platform to grab some tiny extra percentage by learning, developing for, and testing on a new platform?
Good question. A few possible answers:
After all they can happily tell those Linux people "You're unsupported. But try WineX!" When it fails, they simply say "You're unsupported!" They already have your money, after all, and it's your own fault for trying it on an unsupported platform.
If you're unsupported, you're unsupported and you presumably know that when you buy the game. It has nothing to do with the jump table offsets or data structures in use. Smart companies will cater to their customers even when they're using emulation, stupid companies will make up excuses to get out of their obligations.
et's be honest: Isn't WineX just a bandage for all those Linux users (former Windows users) that can't give up Windows games?
What has the fact that they are Windows games got anything to do with it? If Linux users want to play games, let them. Far more important to code in general is how free it is, rather than what APIs it uses. Look at Bleemcast (PSX emulator for Sega Dreamcast). It emulated the original games on a different platform, even with graphical enhancements, but it didn't convince anyone who already had a PSX to jump on the Dreamcast...it just made already-committed Dreamcast owners happier
This is the same old OS/2 argument. The dreamcast died for LOTS of reasons, having emulation wasn't the major factor, if it was a factor at all.
You have to take the intersections, there may be 700k iPods, but you need to eliminate the people who don't have Macs, the people who don't have/want the latest version of MacOS X, the people who aren't aware of this service and the people who would rather get their kicks off the P2P networks rather than pay Apple for it.
Ogg isn't screwed, far from it. In the long term, I suspect it'll be what we all use (I'm talking 10 years maybe here). Historically open systems have won out time and time again over sometimes arguably superior proprietary solutions. GIF vs PNG is a good example given above, the only reason PNG hasn't wiped GIF out is because IE can't do proper transparency without stupid hacks (basically the IE team are lazy asses), and from what we've seen it seems Ogg is keeping pace with the far better funded alternatives easily. Sure, it'll take time, but in a few years AAC will be as relevant to audio as Intel Indeo is to video today.
I'm not sure how much of a blind eye they'll turn, but Windows for instance actually decrypts the audio in the kernel to try and prevent people writing fake audio drivers that dump straight to hard disk.
Sure, today the only way to copy things is to burn to CD and back again. Tomorrow, there'll be a hacky way to do it direct, and the day after there'll be a GUI for it. How many people will say no to their friends? Boom, network effect. That's what the industry is scared of.
The first one seems rather dubious, sure, it might be good enough, but "great" implies better than the rest. The second seems irrelevant, they could have easily built a DRM/encrypted wrapper around Ogg (though I'm sure that'd have gone down like a ton of bricks here ;) and the third seems equally irrelevant, unless Apple actually enjoy paying extra licensing fees.
I rather suspect AAC won out because, as is often the way, the commercial codecs have people with large wallets in the right places with a vested interest in seeing them succeed, while Ogg only has Monty. Plus after having gone to all that trouble to try and make MPEG4 slightly less unfree, they probably wanted to get their monies worth.
When you started, you put a lot of effort into Wine, sponsoring things like WineConf. That didn't work out, but Wine improves constantly, as the latest releases of CrossOver and WineX show. Do you think you'll ever return to it someday, or are you disillusioned with the whole thing?
The confusion may come from the same on Win3.1 being called co-operative multitasking, due to the need for apps to relinquish control manually.
a) They are easier to type
b) They have lots of inertia
There are lots of things we could change, but you have to weigh the improvements against the cost. And really, the improvements for a lot of these things would be mostly cosmetic, and the cost in terms of compatability breaks would be high. So we still use "etc" for config files, even though nobody seems to actually know why it's called that, just because there's a whole load of material out there that relies on that fact.
I'm not really convinced there's a big case against UNIX as a whole in that book. Yeah, it's full of archaic quirks due more to history than anything else, but some of the more braindead stuff is fixed (try killing files with tar cf foo, it won't work on Linux). The criticisims of X resources and xauth are valid, but pretty much anything that's been around for a long time has warts. At some point I suspect X authentication will be cleaned up - in fact these days SSH has it integrated anyway, I never needed to play with xauth.
So, while the criticisms may be valid in many respects, very few are large enough really to be worth fixing. I'm sure you could do something much better than UNIX, but then you have to start from scratch with skills, documentation and so on when all you've gained is satisfying an engineers desire for "cleanness", something that rarely if ever impacts users seriously these days.
For OpenDoc, try KParts or Bonobo (i think opendoc was nicer, but arguably KParts or Bonobo are in wider usage).
Quartz - there isn't really one, and for good reason. It kind of sucks. There were efforts to add Display Postscript type capabilities to X, but they were abandoned after it was realised that the approach was flawed. Xr/Xc seem a better way to achieve the same thing.
I'm not sold on the innovation thing. Innovation is not good per se, you have to balance it with all the other factors. If Linux was a super-whizzy ultra-innovative research OS, not only would it have far fewer apps and users, but Ballmer would just be slamming it for not having compatability with anything. You can't win with guys like this.
Anyway, it was decided right back at the start that usefullness was more important than innovation. That doesn't exclude innovation, but people make a really big deal out of these accusations that they probably shouldn't do.
Well, that HTTP.SYS thing sounds quite similar to the TUX in kernel web server switch. Innovation? Not sure. Check out Slicker. UI research. Is the GNOME2 "less is more" philosophy innovative? ReiserFS is really doing some cool things with filing systems.
The problem with "innovation" is that it's so badly defined. Everybody operates under a different definition. So, I don't see much coming out of the computing industry as a whole that I'd class as innovative right now. There are things. Just not many.
I don't think you can make arguments about whether open source is more innovative than proprietary software. I believe innovation is a function of the individual. Sure, there are innovative environments, but for every argument I've seen saying "open source isn't innovative" there are plenty of good counter arguments.
For instance, I would disagree totally with the idea that paid employees are more innovative by definition. The corporate environment is focussed on increasing the value of the company for shareholders - if you have no need to justify profit, you can work on all kinds of things that traditionally probably wouldn't get the green light, and who cares if you fail?
There are also examples of MS innovation, I mean, really innovative stuff like some of the IE bookmarking enhancements that MSR produced a few years ago, that simply never got into the main product. The researchers attitude was, "well we send the product team a report, but we don't know if they read them or not" which stunned me. At least with open source, if somebody doesn't want to implement your innovation, you can fork.
So I haven't seen any convincing arguments that open source isn't innovative. The majority of open source probably isn't, but then the majority of stuff is not innovative, that's part of what makes innovation special and prized.
Can somebody bittorrent the demo? LGP seems to be struggling
I feel you should read the writings of Stallman, in particular the article about the early days of the GNU project. In particular, I'd note that Stallman made a living for many years by selling tapes with emacs on for $150 - it's free software, but people paid for it.
The issue of free software has very little to do with "cheapness", and everything to do with long term benefits for all.
This is a fairly common mistake on Slashdot - stating your position does not make it valid. Stallman has quite eloquently argued that for various social, economic and technical reasons it's better for software to be free than proprietary. He's never said proprietary software is "evil", and apart from some excitable ACs on /. I have yet to see anybody else claim that either.
So, if you want to be taken seriously, you're going to have to:
a) Respond to Stallmans arguments.
b) Provide some of your own showing that proprietary software is a good thing.
Quick tip about the second one - saying "that's how it's always worked" is not an argument.
Your last paragraph confuses me - it appears to imply that free software is always lacking in features to proprietary software. No matter how much I'm willing to pay, I'm unable to get a version of Internet Explorer that has tabs built in, or that has non-lame JavaScript error reporting without crash-prone extra debuggers, which in fact is currently frustrating my work no end (which is why I'm reading slashdot :). Convenience is an entirely separate issue.
And in fact in this case it appears from some of the comments that GNUcash is significantly more stable and integrated on Linux at any rate than MoneyDance. I don't know enough to compare features.
To be more accurate, prelinking allocates each library a unique location in virtual address space and then stores the precalculated GOT (or is it the PLT) in a new section in the binary. That means you only need to do a few links, instead of a lot (due to the ELF fixup semantics, sometimes you get conflicts which must always be linked at runtime).
Indeed. This is probably the most interesting question of all. Linus makes a big thing of being apolitical, of caring only about the code. That's fine when events are rosy. If something unexpected were to happen, what would he do? Without ideals to guide him, how can we predict what he might do?
And if we cannot predict what he might do, if there is no way we can say "Don't worry, Linus will stand up for this", why is he the leader?
Stallman doesn't "push" his ideology onto Linus anymore than Linus pushes political indifference onto Stallman. RMS argues forcefully for certain positions, and you know, many others join in the merry little flamewars, including Linus.
The fact that RMS appears more forceful is simply because he has strong opinions, whereas all too often Linus' opinion seems to be "only the code matters" where that clearly is not true - if everybody used the best tool for the job Linux simply would not exist. I don't think anybody could succesfully argue that no idealism has motivated any Linux development work.
It should be source code compatible with other platforms though. So the binary may be Linux native, but the program itself really is not.
Indeed, I contribute patches occasionally.
You can dismiss my arguments as whatever you like, I don't really care. They're my opinions, and last I checked, everyone was entitled to their own.
Opinions on their own, while acceptable, are generally worthless, especially when you try and convince others using them. You stated many things as fact "Wine hurts Linux", "Linux users are too cheap" etc, and if you're not going to back them up with credible arguments we might as well ignore you - what else can we do?
RMS thinks in a different way to most of us. When he chooses a tool, he wants one that conforms to his ideals because he isn't just thinking about the next 5 minutes, he isn't interested in just solving this problem and moving on. He thinks a long way ahead.
So when you offer him a proprietary piece of software, he won't use it, even if it's more convenient than what he already has. He believes that in the long term, it's the wrong tool for the job, because he takes into account things that to most people are entirely ethereal - things like what kind of society he wants to live in, the long term maintainability of the software, lack of vendor lock in and so on.
I see way too many people slamming RMS for not being pragmatic enough. I think in reality he is very pragmatic, but with a different timeframe for his concerns to most people, leading them to view him as a "nutjob" or having "alien" thinking.
Hi miguel, I've been trying to find the URL for the Hub for a while, but Google isn't helpful. Do you have it?
As in desktop neutral. IMO "Karma Sucks" is wrong, GTK2 is indeed neutral - it has no dependancies on any of the GNOME libraries, it's used in a lot of non-gnome software (gaim, xmms, gimp etc). The fact that GTK is easier to configure in GNOME than KDE is more to do with where the respective developers priorities lie than anything else, KDE could easily write an xsettings front end, but so far have not.
Luckily quite a few top name game developers refuse to use DirectPlay as it requires Windows servers and too many game servers run on Linux these days to ignore.
There could be problems with patents yes, but that's an issue for the whole of Linux (mp3, ntfs etc) not just Wine. And as SDL is simply DirectX done again, patents would cover similar Linux technologies also.