- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
A Cross-Distro Unified Installer Is On The Way
|
|
|
Comments (36)
16 earlier comments in the full thread.
> Probably not if the software in question is proprietary
No EULA that I know of prohibits a how-to document detailing how to get a deb or rpm package working on another distro. Direct repackage into the distro's native format may or may not be prohibited, depending on the EULA.
No EULA that I know of prohibits a how-to document detailing how to get a deb or rpm package working on another distro. Direct repackage into the distro's native format may or may not be prohibited, depending on the EULA.
Slackbuilds and especially AUR for Arch will do the repackaging for you. It's just a matter of unpacking and repacking, so it's fast.
> Slackbuilds and especially AUR for Arch will do the repackaging for you.
I've tried sbopkg for doing that, and it seems to work well, yes.
I've tried sbopkg for doing that, and it seems to work well, yes.
I still wonder if there was "one Linux package management for all distro's", what would be left of the distro's?
It occurs to me if the distro-people stopped reinventing the wheel by duplicating packages which someone else already packaged (but in another format of course), half of their jobs would be lost. Talking about the emperor with no clothes; repackaging stuff are the clothes of distro's!
I think this year on the consumer market already, more money will have been made from selling Android/Linux packages then _all_ other distro's together. Android is less fragmented and it makes it easier to sell packages in return for money. Android shines where Lindows/Linspire CNR (I'd say the first 'modern' appstore) failed. I think "some sort of" Adobe Photoshop Light on Android will happen before Photoshop on Debian / RedHat etc.
So, if making money on Linux packages and having big ISV's make their stuff available for Linux, I think Android already showed the solution. This shows Red Hat, Canonical et. all. probably don't care about making available lots of proprietary software for their platforms, because else they would already have followed the example of Android.
For those needing 3d party proprietary packages, I'm glad Ubuntu seems to do a nice job of copying the AppStore / Android Market.
Of course, most current Linux users don't need proprietary stuff and are happy with the current package management, so for them it's not a problem. But think how good Linux-distro's could be if all package-reinventers started doing real work, fixing configuration problems, testing etc. instead of duplicating efforts done by other distro's before, then we might see even better Linux-distro's.
I think this year on the consumer market already, more money will have been made from selling Android/Linux packages then _all_ other distro's together. Android is less fragmented and it makes it easier to sell packages in return for money. Android shines where Lindows/Linspire CNR (I'd say the first 'modern' appstore) failed. I think "some sort of" Adobe Photoshop Light on Android will happen before Photoshop on Debian / RedHat etc.
So, if making money on Linux packages and having big ISV's make their stuff available for Linux, I think Android already showed the solution. This shows Red Hat, Canonical et. all. probably don't care about making available lots of proprietary software for their platforms, because else they would already have followed the example of Android.
For those needing 3d party proprietary packages, I'm glad Ubuntu seems to do a nice job of copying the AppStore / Android Market.
Of course, most current Linux users don't need proprietary stuff and are happy with the current package management, so for them it's not a problem. But think how good Linux-distro's could be if all package-reinventers started doing real work, fixing configuration problems, testing etc. instead of duplicating efforts done by other distro's before, then we might see even better Linux-distro's.
"Of course, most current Linux users don't need proprietary stuff and are happy with the current package management, so for them it's not a problem."
Not to put too fine a point on an already contentious issue...
It is a problem.
We've tried to use the "open" solutions to things like flash and Java. In many applications they either fail or crash on popular websites. One such website is Pogo.com. 1/3 of the kids we install for have accounts on Pogo and the Openjdk/IcedTea solutions will not allow the page to load correctly or the games to be played.
On our Ubuntu respin, we've eliminated all these apps and libraries and installed the sun-java packages. Even apps or pages that did work on the open solutions work better and faster with the proprietary solutions. Two years of working with both have at least proven that empirically.
I don't know what the answer is when it concerns a unified package installer...it will surely cause angst and conflict, but until we can legally and safely include these proprietary packages with a Linux distro it's bound to be a point of contention.
h
Not to put too fine a point on an already contentious issue...
It is a problem.
We've tried to use the "open" solutions to things like flash and Java. In many applications they either fail or crash on popular websites. One such website is Pogo.com. 1/3 of the kids we install for have accounts on Pogo and the Openjdk/IcedTea solutions will not allow the page to load correctly or the games to be played.
On our Ubuntu respin, we've eliminated all these apps and libraries and installed the sun-java packages. Even apps or pages that did work on the open solutions work better and faster with the proprietary solutions. Two years of working with both have at least proven that empirically.
I don't know what the answer is when it concerns a unified package installer...it will surely cause angst and conflict, but until we can legally and safely include these proprietary packages with a Linux distro it's bound to be a point of contention.
h
Well, that would be a discussion of what part of the Linux users need 3d-party non-Foss software.
I do, because recently Microsoft bribed bought all CAD-vendors to become Windows only; Pro-Engineer and CATIA are recent converts which stopped UNIX-support.
So I agree to Caitlyn: Current package management doesn't suck, but from an enterprise-viewpoint, current package management is a nightmare. Those who say: "Package it for rpm/deb and distro's will take care" didn't understand anything about FOSS I'm afraid.
I mean, why do you want the source if you're not going to hack? Well, most non-coders will say, because it puts _me_ in control.
The very same is true for enterprises: Whenever they release some .exe for Windows, _they_ are in control. But if they make a .deb and one of the 100 Ubuntu-derivatives screws up repackaging (or AUR or sbopkg or alien do?), they're _not_ in control anymore. Packagers will screw their programs, and users will probably complain to the enterprises.
If people want enterprise software on Linux to happen, they have to accept the enterprises which _make_ those software want to be in control of _their_ software, and they're not accepting other people poking in and screwing up their software, and rightly so! Also, duplicating poprietary EULA-software and putting it on gazillion of mirrors is not an option either. Why mirror it a gazillion times anyway, as lots of package managers can download it from the enterprise-source in first place? OK, Debian seems unable to do this without screwing with apt-files and such, but that's a problem which Debian should fix!
Directly downloading from the source (upstream) means package management will loose its job in my opinion; maybe they can hire themselves to enterprises like "software integrators", as that's what they tried to do with their packaging process in first place.
I'm really glad to see Mozilla seems to understand this. I mean, whenever there was a security glitch for Firefox, my sister on Windows had a fix with the auto-update feature almost immediately. I remained prone to the exploit for days, until package managers felt the new release was "stable". I think for an OS which claims to be "more secure than Windows" - this is simply not acceptable or else the security-promise is a big fat lie. So I was pleased to see FF 4.0bpre8 and later do auto-updates - already bypassing package management and therefore showing Linux package management at least partially sucks.
I do, because recently Microsoft bribed bought all CAD-vendors to become Windows only; Pro-Engineer and CATIA are recent converts which stopped UNIX-support.
So I agree to Caitlyn: Current package management doesn't suck, but from an enterprise-viewpoint, current package management is a nightmare. Those who say: "Package it for rpm/deb and distro's will take care" didn't understand anything about FOSS I'm afraid.
I mean, why do you want the source if you're not going to hack? Well, most non-coders will say, because it puts _me_ in control.
The very same is true for enterprises: Whenever they release some .exe for Windows, _they_ are in control. But if they make a .deb and one of the 100 Ubuntu-derivatives screws up repackaging (or AUR or sbopkg or alien do?), they're _not_ in control anymore. Packagers will screw their programs, and users will probably complain to the enterprises.
If people want enterprise software on Linux to happen, they have to accept the enterprises which _make_ those software want to be in control of _their_ software, and they're not accepting other people poking in and screwing up their software, and rightly so! Also, duplicating poprietary EULA-software and putting it on gazillion of mirrors is not an option either. Why mirror it a gazillion times anyway, as lots of package managers can download it from the enterprise-source in first place? OK, Debian seems unable to do this without screwing with apt-files and such, but that's a problem which Debian should fix!
Directly downloading from the source (upstream) means package management will loose its job in my opinion; maybe they can hire themselves to enterprises like "software integrators", as that's what they tried to do with their packaging process in first place.
I'm really glad to see Mozilla seems to understand this. I mean, whenever there was a security glitch for Firefox, my sister on Windows had a fix with the auto-update feature almost immediately. I remained prone to the exploit for days, until package managers felt the new release was "stable". I think for an OS which claims to be "more secure than Windows" - this is simply not acceptable or else the security-promise is a big fat lie. So I was pleased to see FF 4.0bpre8 and later do auto-updates - already bypassing package management and therefore showing Linux package management at least partially sucks.
> Packagers will screw their programs, and users will probably complain to the enterprises.
And the enterprises will do what they've always done: "We don't support that distribution." It's not like people don't screw with .exe installation files under Windows. Half the time you have to just to get it the beeping thing to install.
> I mean, whenever there was a security glitch for Firefox, my sister on Windows had a fix with the auto-update feature almost immediately. I remained prone to the exploit for days, until package managers felt the new release was "stable"
And exactly how many of those glitches were Windows only, Hans?
If enterprises want a Linux distribution they can control, no one's stopping them from forming a entity to create one. The existing distributions don't belong to them, and they have no more say over how the distributions do things than the distributions do over those enterprises' oh so wonderful software.
And the enterprises will do what they've always done: "We don't support that distribution." It's not like people don't screw with .exe installation files under Windows. Half the time you have to just to get it the beeping thing to install.
> I mean, whenever there was a security glitch for Firefox, my sister on Windows had a fix with the auto-update feature almost immediately. I remained prone to the exploit for days, until package managers felt the new release was "stable"
And exactly how many of those glitches were Windows only, Hans?
If enterprises want a Linux distribution they can control, no one's stopping them from forming a entity to create one. The existing distributions don't belong to them, and they have no more say over how the distributions do things than the distributions do over those enterprises' oh so wonderful software.
Um... Hans, by enterprise I did not mean commercial software vendors. I meant the various and sundry companies, organizations and governments that use software in quantity. I meant business environments for the most part. Red Hat has done a fabulous job at penetrating and even dominating (when it comes to Linux, anyway) the enterprise server market. What market share Linux has on the enterprise desktop/workstation is almost all Red Hat as well, at least in North America.
Red Hat does ship with some proprietary software on a second disc, including Java and Flash. helios is absolutely right. Those are essential bits for consumers and businesses alike.
From an enterprise viewpoint there is nothing wrong with Linux package management. From a commercial software vendor there may be but most would never have any interest in supporting little variant distros because their customers don't use them. I know you started by agreeing with me but I must say I don't agree with you.
Red Hat does ship with some proprietary software on a second disc, including Java and Flash. helios is absolutely right. Those are essential bits for consumers and businesses alike.
From an enterprise viewpoint there is nothing wrong with Linux package management. From a commercial software vendor there may be but most would never have any interest in supporting little variant distros because their customers don't use them. I know you started by agreeing with me but I must say I don't agree with you.
Probably because I meant: Shipping proprietary software to home-users (and maybe small companies). Obviously, that's where 'appstores' shine, and where Android is able to outperform desktop Linux.
It's nice for AutoDesk if they can ship AD Inventor to those Fortune 500+ companies running 3-year old versions of Red Hat. However, how many people use those Red Hat versions at home? Why do you think AD offers free student-versions of products like AD Inventor to students? Exactly, those are meant so people can try, learn and master Inventor at home. Right now, the easiest way for me to run that version is by means of using VirtualBox and XP. Because both companies and home users run XP. So if you look no further than the exit door of the enterprise, then they don't have a problem. But let me tell you, there's a world outside the exit door too!
Right now, these kind of AD programs (soon SolidWorks) are the reason why I still can't use Linux exclusively at home. MathLab is another example, they have a Linux version to try at home, but it didn't work for me. Which back then - when I was afraid of VMWare - meant shutting down Linux and starting Windows again! So, this really pertains to reasons why people can't use Linux fulltime, and they might choose not to use it at all. Virtualization makes life easier, but you still need a copy of XP, and in a virtualized environment (VBox) Inventor 9 sometimes hangs.
For Linux, a company like AD would have to support at least two platforms: The no.1. enterprise one (RedHat) and the no 1. for at home. For Windows, it's only one. Of course it's a lame excuse as we can be pretty sure Microsoft talked AD into not supporting Linux, but still it shows it's easier to do Windows for such a company. The same might be true for Photoshop: If it ran on RedHat, large companies might be satisfied. But where do people learn Photoshop lots of times? Right, at home, making pictures in the garden!
I don't know, I don't care and they don't tell; you tell me! You may care about actual details, I care about principle. If it's unsafe by principle I'd rather not use it; otherwise why not use Windows? Besides, you have to understand FF4.0beta on this system is installed as user, and not as root. So any Javascript-exploit may alter system files. I was susceptible to at least one such an exploit, which for me is enough reason not to wait for the slow package management. Apart from that, believing Linux browsers are not prone to exploits is believing in fairytales. If an exploit is found and within a day a patch is made available by the developers of the application, I don't want to wait for over a week before it's available! I have to admit I will install any Flash-cr.. Adobe throws at me, if they deem it safer than the last version. However, currently I can't do it within a day without bypassing the package manager. And if you care about actual details, FF4.0bpre11 isn't in the package manager even yet!
Of course, I might chown those FF4 files to root, but then I'd have to update manually (FF-auto update doesn't work anymore it seems, since it's not able to ask for a root pw) which one might forget. And not all exploits would have to change files I think.
It's not that Linux software installation sucks, I think it's great! But it could be so much better. Instead of four distro's working four days on testing if a security fix doesn't cause the system to become unstable, from a users perspective it would be better if those four distro's worked together and brought back the 'vulnerable' time to only one day!
And then there's reality.
Well, one can dream, isn't it?
BTW If I made packages of ready to assemble furniture and resold those packages to IKEA (acting as their supplier), I wouldn't be happy if they replaced my bolts and nuts, changed the manual and the logo's on the case, because if it fails it makes me look bad. For those furniture, physic distribution is needed, but not for software. So why not directly link the IKEA-warehouse directly to my warehouse? Why 'copy' all my stuff to the IKEA-warehouse? And now suppose there were eight different IKEA's, then all my furniture would end up differently! Why?
Can't the darn 8 different IKEA's agree on one shared warehouse which they manage together? Wouldn't that be cheaper for the end-consumers, be a more efficient use of scarce labour, and result in better overall quality?
It's nice for AutoDesk if they can ship AD Inventor to those Fortune 500+ companies running 3-year old versions of Red Hat. However, how many people use those Red Hat versions at home? Why do you think AD offers free student-versions of products like AD Inventor to students? Exactly, those are meant so people can try, learn and master Inventor at home. Right now, the easiest way for me to run that version is by means of using VirtualBox and XP. Because both companies and home users run XP. So if you look no further than the exit door of the enterprise, then they don't have a problem. But let me tell you, there's a world outside the exit door too!
Right now, these kind of AD programs (soon SolidWorks) are the reason why I still can't use Linux exclusively at home. MathLab is another example, they have a Linux version to try at home, but it didn't work for me. Which back then - when I was afraid of VMWare - meant shutting down Linux and starting Windows again! So, this really pertains to reasons why people can't use Linux fulltime, and they might choose not to use it at all. Virtualization makes life easier, but you still need a copy of XP, and in a virtualized environment (VBox) Inventor 9 sometimes hangs.
For Linux, a company like AD would have to support at least two platforms: The no.1. enterprise one (RedHat) and the no 1. for at home. For Windows, it's only one. Of course it's a lame excuse as we can be pretty sure Microsoft talked AD into not supporting Linux, but still it shows it's easier to do Windows for such a company. The same might be true for Photoshop: If it ran on RedHat, large companies might be satisfied. But where do people learn Photoshop lots of times? Right, at home, making pictures in the garden!
Quoting:And exactly how many of those glitches were Windows only, Hans?
I don't know, I don't care and they don't tell; you tell me! You may care about actual details, I care about principle. If it's unsafe by principle I'd rather not use it; otherwise why not use Windows? Besides, you have to understand FF4.0beta on this system is installed as user, and not as root. So any Javascript-exploit may alter system files. I was susceptible to at least one such an exploit, which for me is enough reason not to wait for the slow package management. Apart from that, believing Linux browsers are not prone to exploits is believing in fairytales. If an exploit is found and within a day a patch is made available by the developers of the application, I don't want to wait for over a week before it's available! I have to admit I will install any Flash-cr.. Adobe throws at me, if they deem it safer than the last version. However, currently I can't do it within a day without bypassing the package manager. And if you care about actual details, FF4.0bpre11 isn't in the package manager even yet!
Of course, I might chown those FF4 files to root, but then I'd have to update manually (FF-auto update doesn't work anymore it seems, since it's not able to ask for a root pw) which one might forget. And not all exploits would have to change files I think.
It's not that Linux software installation sucks, I think it's great! But it could be so much better. Instead of four distro's working four days on testing if a security fix doesn't cause the system to become unstable, from a users perspective it would be better if those four distro's worked together and brought back the 'vulnerable' time to only one day!
And then there's reality.
Well, one can dream, isn't it?
BTW If I made packages of ready to assemble furniture and resold those packages to IKEA (acting as their supplier), I wouldn't be happy if they replaced my bolts and nuts, changed the manual and the logo's on the case, because if it fails it makes me look bad. For those furniture, physic distribution is needed, but not for software. So why not directly link the IKEA-warehouse directly to my warehouse? Why 'copy' all my stuff to the IKEA-warehouse? And now suppose there were eight different IKEA's, then all my furniture would end up differently! Why?
Can't the darn 8 different IKEA's agree on one shared warehouse which they manage together? Wouldn't that be cheaper for the end-consumers, be a more efficient use of scarce labour, and result in better overall quality?
> For Windows, it's only one.
Not really. Any company still has to support XP, Vista, and Windows 7. Many may choose to still support 2000. And the changes between XP and Vista were as significant as the differences between distributions in Linux.
> ..which for me is enough reason not to wait for the slow package management.
Hans, Slackware usually has a Firefox update out within 24 hours after it's released. That's not slow.
And the upstream download you're talking about is exactly how sbopkg works. It downloads the source or binary package directly from the upstream provider and repackages it on the fly.
Not really. Any company still has to support XP, Vista, and Windows 7. Many may choose to still support 2000. And the changes between XP and Vista were as significant as the differences between distributions in Linux.
> ..which for me is enough reason not to wait for the slow package management.
Hans, Slackware usually has a Firefox update out within 24 hours after it's released. That's not slow.
And the upstream download you're talking about is exactly how sbopkg works. It downloads the source or binary package directly from the upstream provider and repackages it on the fly.
I'm using Ubuntu, and I get my security updates of Firefox withing 24 hours... not the main repository to be sure, but neverthe less. I simply installed Ubuntu Tweak and linked to the appropriate PPA.
Quoting:Not really. Any company still has to support XP, Vista, and Windows 7.
Doh, there's also RHEL 3, RHEL 4, RHEL 5 etc, of course they're different over time. It's not like there's any difference. What I mean is, Windows 7 is used currently (at the same time for argument's sake to stop the nonsensical XP/Vista/7 comments, and moreover, of course companies don't have to support them all!) both for enterprise desktops and home users. I'm sure you already understood.
sbopkg is almost there (why repackage it on the fly if it's directly from upstream in first place? Then you can "download it on the fly" as well!), but it's not what most distro's are using. And if some distro ships updates within 24 hours, then why not directly use it from upstream without any interference from the distro in any kind? See, nearly there! I mean, with the new Mozilla system I can install updates at the same time they are to _any_ distro. The drawback is before you know it, you have a Windows-system where 20 apps beg to update, but luckily in Firefox this is done "invisibly" without asking, a bit like using the average -q switch.
Firefox is not the best example. If you install the Mozilla build, you can start Firefox as root and it will update automatically, just like in Windows.
> ...why repackage it on the fly if it's directly from upstream in first place?
So that updates, removal, reinstall, or repair can be handled by the distribution's package tools.
So that updates, removal, reinstall, or repair can be handled by the distribution's package tools.
jd: Windows can do that - apart from the updates maybe - without any repackaging. Mozilla shows it can do updates without package manager.
But enough about what lacks, what would be nice is too have some central repository shared by Linux distro's, where the package is in control of the developer of the application. If apt does A, rpm does B and some other does C, then design something which does A, B and C. Of course, probably not going to happen because most of the time teams who're doing redundant work are not going to admit it.
But enough about what lacks, what would be nice is too have some central repository shared by Linux distro's, where the package is in control of the developer of the application. If apt does A, rpm does B and some other does C, then design something which does A, B and C. Of course, probably not going to happen because most of the time teams who're doing redundant work are not going to admit it.
> ...what would be nice is too have some central repository shared by Linux distro's, where the package is in control of the developer of the application.
Hans, anyone can set up a deb/rpm/tgz repository and give directions for adding it to your distribution. Skype used to do that: http://forum.skype.com/index.php?showtopic=29679 , and I believe that is what Canonical is trying to accomplish with their "Partner Repositories".
What you want can already be done easily. All the vendors have to do is set up a common repository so people can add it. Even Slackware could handle that with slapt-get.
Hans, anyone can set up a deb/rpm/tgz repository and give directions for adding it to your distribution. Skype used to do that: http://forum.skype.com/index.php?showtopic=29679 , and I believe that is what Canonical is trying to accomplish with their "Partner Repositories".
What you want can already be done easily. All the vendors have to do is set up a common repository so people can add it. Even Slackware could handle that with slapt-get.
But there's no central place to register 3d party repositories, and moreover 3d party repositories shouldn't be necessary in first place. Linux kernel doesn't have 3d party repositories, and if it does (like Android) people hail those companies for it. Then why do Linux packages need 3d party repositories? If the model works for the kernel (and it does because lots of companies are adding to the kernel), then why not for packages?
> But there's no central place to register 3d party repositories...
No one's stopping the vendors from setting one up. If they think it's that big of a problem, and the solution is so obvious, why aren't they doing it?
Answer: Because they simply don't want to support Linux. The reasons they give are excuses.
> ...If the model works for the kernel (and it does because lots of companies are adding to the kernel), then why not for packages?
Because there's one kernel (that's not quite true, but it's pretty close). There are lots of distributions. Again, if the vendors don't want to support them all, pick one or two to support. Again, the answers to their supposed problems have always been obvious. If they wanted to support Linux, they would be doing so.
No one's stopping the vendors from setting one up. If they think it's that big of a problem, and the solution is so obvious, why aren't they doing it?
Answer: Because they simply don't want to support Linux. The reasons they give are excuses.
> ...If the model works for the kernel (and it does because lots of companies are adding to the kernel), then why not for packages?
Because there's one kernel (that's not quite true, but it's pretty close). There are lots of distributions. Again, if the vendors don't want to support them all, pick one or two to support. Again, the answers to their supposed problems have always been obvious. If they wanted to support Linux, they would be doing so.
From reliable sources, I heard at least one of the "WindowsOnly" CAD vendors is (trying to) go(ing) 'web/cloud-based'. Which - I'm pretty sure - means running on Linux, and I'm also pretty sure it means the other ones are following. So, gladly the web fixes the "control-problem" where Linux-distro's failed: Finally those vendors can deliver software to end-users on Linux without being reliant on "package managers and repackaging systems". I hope it'll end up in Ubuntu's store.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
Probably not if the software in question is proprietary, as the eula would probably prohibit it.