He may not manage them in the traditional sense of the word, but when they are making statements to driver developers that flatly contradict Linus' official policy and he does nothing, that seems to me very poor project management indeed. He should at least contradict them, if nothing else.
I don't think you know that much about hardware design. Neither do I really, but one thing I do know is that moving things into the driver can often increase performance, for instance texture compression is one obvious example. It's not just a case of manufacturers being too cheap to do it, sorry.
Finally as to them being "evil", well I don't really care - this is the way the system works. If instead of screwing over 3rd party driver devs constantly, these kernel people figured out an economic model that didn't need patents and didn't punish openness, I'd be more impressed. Instead they try and address the symptoms and think it'll have some real effect.
Releasing GPLd drivers doesn't make it all magically better. It's not like any GPLd code is accepted into Linus' tree, and it's not like once it's in it's in forever.
Attempting to make one kernel tree support every piece of hardware in the world just isn't going to fly, but some of the hard-liners who write the kernel apparently prefer bad hardware support to non-GPLd drivers.
That's probably because key kernel developers make a sport out of breaking the nVidia drivers (really, any binary only drivers) because they are "evil". Greg KH is particularly nasty about this. He doesn't seem to care about the underlying reasons they aren't open sourced, he just doesn't want people to use them. Go choice!
The fact that Linus lets high level kernel developers get away with saying that they think binary modules are completely illegal increasingly convinces me that no matter how great an engineer he is, he knows shit all about managing his people.
Hah, too true! I did exactly the same thing. I don't even think about it anymore.
Actually on operating system related stories BWJones almost always posts OS X fanboyism. On non-operating system stories his posts can be pretty interesting, but if I want to read Apples marketing material I'll go to apple.com thanks.
Yeah, I seem to recall reading that Red Carpet was what kicked things off. Novell wanted good network management tools and RC fitted the bill nicely. Ximian also had the Ximian Desktop which was proof that their people knew how to build easy to use, slick software - something the KDE people still seem to be struggling with.
Buying TrollTech wouldn't have done much for them. Liberalising the license on Qt would just have cost them money as that's TrollTechs revenue stream, and why bother when Red Hat is already funding GTK+ development quite heavily?
It'll try and download ("resolve") the dependency, there is a screenshot of this happening in the gallery. It's the one with the big globe picture. Right now it can only do that if there is an autopackage of the dependency too. In future it'll get smarter.
He means vnc2swf, and yes the demo was made using only free software. I have not checked if swfdec can play it, but I suspect it can as the subset of flash used is quite basic.
Guys, if you really care that much (reality check: it's just a path), change the default install location in the/etc/autopackage/config file to/usr/local - it won't complain. Just don't come crying to us when random stuff breaks because your distro isn't set up right.
Possibly not, but very few packages do this right now. I think we need more real world experience first.
When a feature isn't working in a program because a library is missing there is nothing to stop that program telling the user to install XYZ library to get that feature, and in future with a PAL doing it itself MSI-stylie.
Finally yes, reporting back to the packagers which deps fail most frequently is something we want to do (so people can get a better understanding of what problems their users are having).
Sure, I didn't mean *all* Gentoo users were like that. But you have to admit it is a fairly commonly raised point, even if many users know it doesn't make that much of a difference.
I have, and you apparently aren't using the same definition of static linking as used on Linux. I do not mean including a framework inside another framework that is then automagically shared (except when it's not, for various inscrutable reasons). I'm talking about toolchain/compile level static linking. You can "statically link" shared libraries using rpath tricks and such on Linux too, however this technique isn't always useful.
Yes, that's what virtual dependencies / capabilities in both rpm and dpkg provide. As for files moving around, that's what the FHS is for.
I'm afraid the FHS is a mostly useless document that is far, far too vague to deserve the title of "standard". Many distros ignore it, or interpret it differently. Virtual dependencies/capabilities and so on are fine solutions inside a particular distribution but there are no standards. This boils back down to dep metadata differences.
But in reality, you don't encounter this scenerio untill you install rpms/ debs on another distro. Big deal: binary packages will always be built against specific library versions. Autopackage doesn't solve that.
Are you sure it doesn't solve that? Because it seems to me that it would not work if it didn't, yet it does work. Here are some keywords for you: "relaytool", "binary stability", "dependency audit". I think you should open your mind a little and explore the project more before writing it off.
That's a human problem. You can't fix it with technology. Taking away the ability to have custom macros is a bad thing. Encouraging proper behavior is a better thing.
I never said custom macros were bad, merely pointing out that they cause inter-distro package incompatibilities. You're quoting from the section "Why are RPMs I find on the net not portable between distributions". It's not a slam against RPM, just a statement of the facts. I wouldn't take it personally.
Both OSS projects and proprietary vendors including Adobe's, BEAs, Macromedia etc. all release properly packaged binaries.
Most proprietary vendors release RPMs with virtually no dependency data at all, certainly not packages suitable for use with apt or similar depsolvers. They are basically being used as magic tarballs.
And frankly, I like having a database.
Sure, we all do. Autopackage has a database and can list files/file ownership too. It also checksums files. Again, you seem to be writing it off without knowing anything about (gee, exactly what you're accusing me of!). It's not integrated with the native database yet because there are a whole class of users who care more about getting the software onto their system than what form it comes in, but I'm sure somebody will step up and write the support eventually: there are already architectural hooks for it. Who knows, maybe I'll do it.
Really, you should just chill out a bit. Even if you hate it, remember that many people don't give a monkeys about checksumming files in a database: they just want it to work and saying "I won't install this because it's in the wrong form" is no solution.
I disagree. I think it was perfectly predictable that people would want to install things outside of the apt repositories, just installing from source tarballs is very common. Not anticipating this is a design problem with apt/rpm but one that won't be fixed anytime soon.
No it's not possible. Read the packager quickstart, making an autopackage is not a mechanical process and usually involves patching (improving) the software itself.
We already do that, using the recommended() call instead of require() will cause autopackage to try and resolve the dep if possible, if not it won't halt the install though. So we already do a best-effort attempt to install every feature possible.
The autopackage FAQ has "what's wrong with NeXT/MacOSX style appfolders", but it seems to consist mostly of hand-waving and straw men. They don't seem to understand how NeXT/Mac apps work, e.g., w.r.t. linking.
Could you elaborate please? Of course it's possible to build a system that uses appfolders, NeXTStep is one, however:
Doing that on Linux is hard, because of dependencies and the lack of a large platform. I'm not interested in theoretical systems, I'm interested in what I use which is Linux. I'm also not interested in MacOS X because I don't use that, and because it's proprietary which is totally not the way forward for our society.
Linux isn't designed to allow appfolders
easily. The freedesktop.org specs are oriented around the concept of "drop a file in this directory, update a cache". This works well for package managers, less well for appfolders. It's done that way for valid reasons: the menu system is designed with administrators, windows compatibility and internationalization in mind. The appfolders menu system isn't really designed per se, it's just a convention to put stuff in/Applications (and a shockingly large number of apps break if they aren't in/Applications).
The issues with linking etc are well known. Yes I understand how MacOS X linking works, that includes how frameworks work and also the weak linkage Apple use. Before suggesting we don't understand linking how about reviewing things like apbuild and relaytool. Nonetheless, new libraries are manufacturered at a quite astonishing rate on Linux: the openness lends itself to massive and extremely fine grained code reuse. That means we can't just rely on having a bigass platform, though one would be nice. Dep resolution is still important simply to prevent your OS becoming totally obsolete within a year.
The only person who has really done serious work with appfolders on Linux is Thomas Leonard, an extremely smart man who was behind the ROX desktop. Note that appfolders aren't a Mac or NeXT invention, they were done by RISC OS back when I was a wee kid.
As Thomas found out, dependencies are kind of a tricky problem with appfolders. His solution was ZeroInstall, a very nice piece of work I must say. However it had issues, as software often does, and now he is designing something called the "Injector". This has quite a few concepts similar to autopackage, namely management of interfaces and dependencies. So in the process of "fixing" appfolders to have all the features people wanted, he ended up with something that vaguely resembles systems like autopackage and apt-get. Note: that doesn't mean to imply that the Injector is useless or anything, it's not and has some good ideas. I encourage people to check it out!
Just be aware that appfolders tend to evolve into installers eventually. They did on DOS, RISC OS, and of course on MacOS X as well (iTunes comes in an installer and it's not the only one....)
Autopackage does support dependency resolution. And yes, it would be nice for it to integrate with dpkg/rpm so tools like apt can "see" it. The ignorance of apt to software not installed by it is a failing of apt not autopackage, but one we must work with. Doing so has been on the roadmap for a long time now, but as it's so very rare for one application to depend on another (think word processor needing drawing app - rare) it wasn't deemed essential to 1.0
Actually relaytool can work for any language GCC supports, so that's C/C++/Java/Objective-C and a few others. However you are right. Relaytool is a hack. Better solutions involve modifications to ELF (eg DT_WEAK_NEEDED) or the use of LLVM.
Not falling back when things are missing isn't really an option, the aim is to make installs as easy as possible so having minimal dependencies is crucial. Requiring people to have features XYZ compiled in is rather Gentooish: most non-technical users won't understand what this problem is let alone how to fix it.
Tracking user prefs, yes maybe. Right now user interaction is banned so we can support drag/drop installs though. Hmm.
Yes. It's not just a matter of the $PATH. It's a case of menu setups, file assocations, icon paths, desktop setups, linker cache configurations etc etc. The list goes on and on. Even if you find a perfect distro that gets all this right, it doesn't matter, we have to support all distros.
Of course we want to integrate with DPKG as well, why would we not? It's just easier to use RPM as a shorthand for "RPM and all systems like it", that's all.
You can package C++ programs with autopackage, Inkscape is an obvious example. The big issue is with KDE apps because they link to huge C++ ABIs. Debians packaging system doesn't solve this problem, it merely hacks around it by forcing you to upgrade everything at once (except when it doesn't).
We have kicked around a few ideas for improving the C++ support in autopackage. For instance, using xdeltas to ship both ABIs in one box. As the ABI differences between gcc 3.3 and 3.4 are quite small this may prove effective. So far nobody has stepped up to implement this though.
Using systems like alternatives (which is btw implemented on Fedora too) is perfectly possible: tight integration has always been a goal. There would need to be some API to abstract this out but that's not too hard.
A short word about this. The right way to do this in a distributed environment IMHO is to use something like LLVM to ship binaries in a CPU architecture independent format. This has several advantages:
LLVM images tend to be smaller than ELF images as the bytecode format is more compact than x86 code is
The VM can produce native code without any virtual machine overhead at install time, whilst still optimising based on the CPU features available at runtime. This gives such binaries the same advantages that Gentoo users tout as being an advantage of compiling everything as all binaries are fully optimised for your CPU, but without the massive speed hit that C/C++ parsing implies.
As new architectures are introduced there's no need to recompile packages, you can use the pre-existing ones after writing an LLVM backend
The LLVM image format is quite good, and more easily extended than ELF. So things like relaytool become no longer necessary because we can fix it in the binary format rather than having to hack around it.
Nobody is working on integrating LLVM and autopackage right now though.
Are you sure about that? How do you know there are no more exploits? Do you have some power of clairvoyence nobody else does?
The thing that concerns me about the DMG exploits, is that they were caused by the fundamental design of the system not simple typos/poor coding practice. Having appfolders integrate with the system by registering file associations/URL handlers silently through the shell seems like the obvious way to handle this stuff in an "install free" environment, though really it's just doing the install at a later time. But it had unintended side effects which were devastating for security.
The problem is, to solve this you either have to go back to some explicit action integrating software with the system, or pile on more hacks to try and solve the security exploits. Apple chose both - Tiger boasts an improved installer, iTunes comes inside a package etc. But the approach they took with Safari reminds me of Internet Explorer: cover up a flawed technology like ActiveX with more and more hacks and security restrictions that somehow always managed to leak.
You are right that most applications should not need to modify the "system" to run. This is the principle behind authentication-less installation, which we only approximate on Linux with the install to $HOME feature in autopackage. Figuring out the exact set of permissions that are safe for installers to have and then enforcing them is somewhat tricky: both Windows and MacOS X are riddled with programs that demand the administrator password which implies that so far, nobody quite identified the sweet spot.
Slashdot Mirror
I don't think you know that much about hardware design. Neither do I really, but one thing I do know is that moving things into the driver can often increase performance, for instance texture compression is one obvious example. It's not just a case of manufacturers being too cheap to do it, sorry.
Finally as to them being "evil", well I don't really care - this is the way the system works. If instead of screwing over 3rd party driver devs constantly, these kernel people figured out an economic model that didn't need patents and didn't punish openness, I'd be more impressed. Instead they try and address the symptoms and think it'll have some real effect.
Attempting to make one kernel tree support every piece of hardware in the world just isn't going to fly, but some of the hard-liners who write the kernel apparently prefer bad hardware support to non-GPLd drivers.
The fact that Linus lets high level kernel developers get away with saying that they think binary modules are completely illegal increasingly convinces me that no matter how great an engineer he is, he knows shit all about managing his people.
Actually on operating system related stories BWJones almost always posts OS X fanboyism. On non-operating system stories his posts can be pretty interesting, but if I want to read Apples marketing material I'll go to apple.com thanks.
Because MSN is the de-facto standard in Europe. It's even more dominant than Windows is. Who cares what "works", if your friends don't use it?
Buying TrollTech wouldn't have done much for them. Liberalising the license on Qt would just have cost them money as that's TrollTechs revenue stream, and why bother when Red Hat is already funding GTK+ development quite heavily?
It does not. It's a part of the ELF specification and if your dynamic linker does not support it, it does not support ELF.
It'll try and download ("resolve") the dependency, there is a screenshot of this happening in the gallery. It's the one with the big globe picture. Right now it can only do that if there is an autopackage of the dependency too. In future it'll get smarter.
He means vnc2swf, and yes the demo was made using only free software. I have not checked if swfdec can play it, but I suspect it can as the subset of flash used is quite basic.
Guys, if you really care that much (reality check: it's just a path), change the default install location in the /etc/autopackage/config file to /usr/local - it won't complain. Just don't come crying to us when random stuff breaks because your distro isn't set up right.
When a feature isn't working in a program because a library is missing there is nothing to stop that program telling the user to install XYZ library to get that feature, and in future with a PAL doing it itself MSI-stylie.
Finally yes, reporting back to the packagers which deps fail most frequently is something we want to do (so people can get a better understanding of what problems their users are having).
Sure, I didn't mean *all* Gentoo users were like that. But you have to admit it is a fairly commonly raised point, even if many users know it doesn't make that much of a difference.
By the way I don't consider putting up warnings to be a "fix". After all, that worked wonders for ActiveX didn't it?
I have, and you apparently aren't using the same definition of static linking as used on Linux. I do not mean including a framework inside another framework that is then automagically shared (except when it's not, for various inscrutable reasons). I'm talking about toolchain/compile level static linking. You can "statically link" shared libraries using rpath tricks and such on Linux too, however this technique isn't always useful.
Yes, that's what virtual dependencies / capabilities in both rpm and dpkg provide. As for files moving around, that's what the FHS is for.
I'm afraid the FHS is a mostly useless document that is far, far too vague to deserve the title of "standard". Many distros ignore it, or interpret it differently. Virtual dependencies/capabilities and so on are fine solutions inside a particular distribution but there are no standards. This boils back down to dep metadata differences.
But in reality, you don't encounter this scenerio untill you install rpms/ debs on another distro. Big deal: binary packages will always be built against specific library versions. Autopackage doesn't solve that.
Are you sure it doesn't solve that? Because it seems to me that it would not work if it didn't, yet it does work. Here are some keywords for you: "relaytool", "binary stability", "dependency audit". I think you should open your mind a little and explore the project more before writing it off.
That's a human problem. You can't fix it with technology. Taking away the ability to have custom macros is a bad thing. Encouraging proper behavior is a better thing.
I never said custom macros were bad, merely pointing out that they cause inter-distro package incompatibilities. You're quoting from the section "Why are RPMs I find on the net not portable between distributions". It's not a slam against RPM, just a statement of the facts. I wouldn't take it personally.
Both OSS projects and proprietary vendors including Adobe's, BEAs, Macromedia etc. all release properly packaged binaries.
Most proprietary vendors release RPMs with virtually no dependency data at all, certainly not packages suitable for use with apt or similar depsolvers. They are basically being used as magic tarballs.
And frankly, I like having a database.
Sure, we all do. Autopackage has a database and can list files/file ownership too. It also checksums files. Again, you seem to be writing it off without knowing anything about (gee, exactly what you're accusing me of!). It's not integrated with the native database yet because there are a whole class of users who care more about getting the software onto their system than what form it comes in, but I'm sure somebody will step up and write the support eventually: there are already architectural hooks for it. Who knows, maybe I'll do it.
Really, you should just chill out a bit. Even if you hate it, remember that many people don't give a monkeys about checksumming files in a database: they just want it to work and saying "I won't install this because it's in the wrong form" is no solution.
I disagree. I think it was perfectly predictable that people would want to install things outside of the apt repositories, just installing from source tarballs is very common. Not anticipating this is a design problem with apt/rpm but one that won't be fixed anytime soon.
No it's not possible. Read the packager quickstart, making an autopackage is not a mechanical process and usually involves patching (improving) the software itself.
We already do that, using the recommended() call instead of require() will cause autopackage to try and resolve the dep if possible, if not it won't halt the install though. So we already do a best-effort attempt to install every feature possible.
Could you elaborate please? Of course it's possible to build a system that uses appfolders, NeXTStep is one, however:
The only person who has really done serious work with appfolders on Linux is Thomas Leonard, an extremely smart man who was behind the ROX desktop. Note that appfolders aren't a Mac or NeXT invention, they were done by RISC OS back when I was a wee kid.
As Thomas found out, dependencies are kind of a tricky problem with appfolders. His solution was ZeroInstall, a very nice piece of work I must say. However it had issues, as software often does, and now he is designing something called the "Injector". This has quite a few concepts similar to autopackage, namely management of interfaces and dependencies. So in the process of "fixing" appfolders to have all the features people wanted, he ended up with something that vaguely resembles systems like autopackage and apt-get. Note: that doesn't mean to imply that the Injector is useless or anything, it's not and has some good ideas. I encourage people to check it out!
Just be aware that appfolders tend to evolve into installers eventually. They did on DOS, RISC OS, and of course on MacOS X as well (iTunes comes in an installer and it's not the only one ....)
Autopackage does support dependency resolution. And yes, it would be nice for it to integrate with dpkg/rpm so tools like apt can "see" it. The ignorance of apt to software not installed by it is a failing of apt not autopackage, but one we must work with. Doing so has been on the roadmap for a long time now, but as it's so very rare for one application to depend on another (think word processor needing drawing app - rare) it wasn't deemed essential to 1.0
Not falling back when things are missing isn't really an option, the aim is to make installs as easy as possible so having minimal dependencies is crucial. Requiring people to have features XYZ compiled in is rather Gentooish: most non-technical users won't understand what this problem is let alone how to fix it.
Tracking user prefs, yes maybe. Right now user interaction is banned so we can support drag/drop installs though. Hmm.
Yes. It's not just a matter of the $PATH. It's a case of menu setups, file assocations, icon paths, desktop setups, linker cache configurations etc etc. The list goes on and on. Even if you find a perfect distro that gets all this right, it doesn't matter, we have to support all distros.
You can package C++ programs with autopackage, Inkscape is an obvious example. The big issue is with KDE apps because they link to huge C++ ABIs. Debians packaging system doesn't solve this problem, it merely hacks around it by forcing you to upgrade everything at once (except when it doesn't).
We have kicked around a few ideas for improving the C++ support in autopackage. For instance, using xdeltas to ship both ABIs in one box. As the ABI differences between gcc 3.3 and 3.4 are quite small this may prove effective. So far nobody has stepped up to implement this though.
Using systems like alternatives (which is btw implemented on Fedora too) is perfectly possible: tight integration has always been a goal. There would need to be some API to abstract this out but that's not too hard.
A short word about this. The right way to do this in a distributed environment IMHO is to use something like LLVM to ship binaries in a CPU architecture independent format. This has several advantages:
Nobody is working on integrating LLVM and autopackage right now though.
The thing that concerns me about the DMG exploits, is that they were caused by the fundamental design of the system not simple typos/poor coding practice. Having appfolders integrate with the system by registering file associations/URL handlers silently through the shell seems like the obvious way to handle this stuff in an "install free" environment, though really it's just doing the install at a later time. But it had unintended side effects which were devastating for security.
The problem is, to solve this you either have to go back to some explicit action integrating software with the system, or pile on more hacks to try and solve the security exploits. Apple chose both - Tiger boasts an improved installer, iTunes comes inside a package etc. But the approach they took with Safari reminds me of Internet Explorer: cover up a flawed technology like ActiveX with more and more hacks and security restrictions that somehow always managed to leak.
You are right that most applications should not need to modify the "system" to run. This is the principle behind authentication-less installation, which we only approximate on Linux with the install to $HOME feature in autopackage. Figuring out the exact set of permissions that are safe for installers to have and then enforcing them is somewhat tricky: both Windows and MacOS X are riddled with programs that demand the administrator password which implies that so far, nobody quite identified the sweet spot.