If the developers have said "this is the only format we're releasing our software in" then yes, I consider it released. Plenty of projects refuse to make distro specific packages. So they are using automake as their "installation API." So you would consider such projects "never released." Which to me shows an attitude problem in the community.
At the very most, it shows an attitude problem in me. I in no way represent any community whatsoever!
Have you tried to read the Illiad? There is more humanity in the couple of pages in which Patroclus dies, more thickness in the characters involved, than in the whole impressive stack of papers the script for the 6 movies must make.
Try it, really.
There are some interesting ideas in the original movies, specially the `used future' which someone remarks somewhere else in this thread, but as soon as you judge it from the point of view of someone who is not attached to the movies emotionally, the story is crap, the characters absurdly empty, the tension nil.
I didn't mention releasing of source at all. Having the source or not is irrelevent to this topic, in my mind. Now releasing software, yes, it should be installable by someone on the target system.
It is relevant in so far you seem to consider that if someone releases the software in source form, it should be installable by end users. I, on the other hand, only consider software to be released to users when it is released in a way they can be expected to handle.
99% of Windows users will not be able to install software which is not packaged, and you clearly do not consider that as a fault in that platform. Why do you think that regular users not being to install software which was not packaged for them is a problem in the Linux platform (whatever that meay mean)?
I never said it was insurmountable, I said it throws up challanges needlessly. As a developer, I don't want to package my application 18 different ways. As a user, I want a single consistent way to install and manage my applications. It's an obsticle, and given that I had problems with it, I couldn't imagine say my sister not having problems. If you only get your software from your distribution supplier, I guess you'd be ok. The problem is that developers whose software DOESN'T get included have a problem of getting installed.
Your sister would never have that problem, because she is probably not even aware that there is another way to install software apart from nicely packaged packages trimed for their platform, whether that platform be Linux in some variant or Windows.
The IM client I was talking about was Kopete. And it wasn't that there was something wrong with the package, it was that the newest version would ONLY work with the newest libraries for KDE, which broke other applications on my system (once I satisfied the 30 or so dependencies I needed to update). It also broke some applications installed via automake.
But then you were trying to do something that even the Kopete developers did not intend users to do (I trust them enough to not take them for idiots). Clearly, they based their latest release on versions of libraries which are not yet common.
They evidently did a release intended for integrators. Integrators should not have any problem setting up things and, in turn, packaging the package for end users.
If installing the newest KDE libs broke existing apps, then the new libs were not compatible with the old ones and therefore either they were intended to break compatibility (if that is the case, I am sure the KDE people have set things up so as to have parallel installability) or there is a major bug. In the second case, well, shit happens; in the first, then you must have done something wrong. You will say that is should be easier to do this correctly, but you should take into account that what you tired to do is change a basic library on which the whole desktop depends (if you are using KDE,at least), so that is a seriously major change to your system, which should be considered only when doing system-wide updates. And users simply do not do that.
Maybe things have improved, like I said. But that was my experience with Mandriva in 2006. After Linux on the desktop for five years, I finally threw up my hands in disgust with all the nonsense I had to go through whenever I tired to update my system or install new software, and it drove me to not only go back to Windows on the desktop, but to replace my long running Linux server.
Clearly, an example of YMMV.
Anyway, I'm not trying to bash Linux, but unless there have been signficiant updates, Linux has a long way to go in this area, and my claim that having too many distros / package managers is part of the reason. Take all the good ideas from each one, and make ONE that works really well, and make it part of the LSB. There is such a thing as "too much of a good thi
Well, complaining usually gets you "this is free, take it or leave it." Also, why bother, when with Windows any software you buy will have an installer.
If they tell you that, then do not use their software. Consider it the analogue of a non-free-as-in-beer software developer charging you a billion dollars for their app: would you buy it at that price?
What are those two completely different ways you have inmind? You can't possibly mean `from sources' and `using package management'... The only reason you do not have this problematic alternative with non-OSS software is because you do not have the source! So you concede that exposing Automake to users is bad, and when I say that there's a lot of OSS software "installed" that way, and the other half is installed via a package management system, you quipe it's not a problem in Windows because I don't have the source? As a user, I don't care about the source. I just want the software that works. I don't care how a cow is milked, I just want to be able to drink the milk.
No. I was just trying toguess what are these `two completely different ways of installing apps' you referred to but did not mention.
Right, because they are only given the option of installing software that's been packaged. Have any of your users found software that WASN'T packaged for their system, and wanted it installed? Have you had a user that found a package, but couldn't install it on Fedora because it was a deb package? As a developer, I've come across such things, and I'm not talking about development software either. IM clients, torrent cilents, etc.
You seem to believe that someone releasing the source of some app should magically make it installable for anyone. That does not apply in the Linux world, because most people will have no idea of how to proceed, and it does not apply in the Window world, because of the same reason, and I'd say it does not apply in any world.
I consider `releasing an application' for users to mean `releasing it in user usable form'. That someone wrote an IM client and put the source somewhere in the internet is not releasing it in a user usable form. If the IM client developers simply puts the source out there, then he is not making it available for users. `User usable form' means packaged in a way users can use it. The developer may not care about doing it, but that is his prerrogative.
You should note that there is quite a lot of people who've somehow managed to get past this insurmountable amount of problems you keep talking about, commercial and non-commercial, open-source and non-open source. It surely could be easier (but I would not want to use an internet-facing IM client written by a developer who cannot grok the rpm.spec format...), but as usual, every could be easier.
Of course! But automake makes it trivial for the developers/distributors to adapt to local conventions. It is developers who have to package things for users. A package that requires the user to even know of automake to install is broken.
Yet for many OSS projects, this is the only want to install.
Then complain to the developers of those OSS projects.
You do understand that no one is in a position to tell every OSS developer (whatever that may mean!) to stop being a fool and provide a sensible way for their app to be installed.
What issue are you talking about, specifically? I never have this problem you speak of, and I have not only lots and lots of free software installed, from my distro, from other distros and compiled by hand, but also proprietary software, and I have not seen this problem.
Well the fact that there are at least two completely different ways to install software on Linux doesn't help. The fact that each distro seems to create their very own package management amplifies the problem.
What are those two completely different ways you have inmind? You can't possibly mean `from sources' and `using package management'... The only reason you do not have this problematic alternative with non-OSS software is because you do not have the source!
It does not matter what package management a distro picks: if it is a user-oriented distro, and it is good at that, then the user will have absolutely no interaction with the package tools apart from pointing, clicking, and so on. I know absolutely computer-illiterate people who from time to time install apps on Ubuntu and Fedora, and who do not know that the underlying packaging systems are different.
What you are complaining is about half-finished attempts at interfaces to packaging systems. But the variety of packaging systems is irrelevant to your problem: your problem lies entirely with the `half-finished' part. Again: what's new?
Everything can fail. What's new?
Automake or even RPM installations have failed for me many more times than installtion of programs on Windows. Windows has an entire API available to developers to consistently install programs. Why isn't there such a thing in Linux?
Well, from the developer's point of view, RPM is an API. So is the debian packaging format.
You have had failures installing, I haven't in ages (at least, since I left Slackware, which characteristically has a utmostly primitive pacaging system) What problems have you had? With what packages? How can you possibly tell it is not the developer's fault instead of the package format's, and that they would not have screwed up using any other API?
There are standard locations for essentially everything 95% of the software out there needs to install, and essentially everything 95% of the software out there needs to function is placed in standard locations. Developers need to be aware of the standard conventions (the LSB, for example), and that is not in any way different to needing to know the relevant.Net API.
I don't see it much different. The API exists to help developers adhere to the guidelines. In the Linux world, it seems to be individual distrubutions to provide ways to install programs. As I said, the problem is that Redhat puts some files in different locations than a Deb based distro. Does the LSB even address that? Why doesn't the LSB include some kind of installer API?
What files? Why are apps dependent on where those files are?
Do you know that an RPM file does not have hard-coded the locations where its files will be put, but instead at rpm-installation time the rpm program reads a configuration file which tells it where the different pieces should go? And that it is trivial to install a rpm in a debian box configured to have it follow the debian standards? I am quite sure dpkg allows fore exactly the same.
The thing is, automake shouldn't be seen by an end user.
Of course! But automake makes it trivial for the developers/distributors to adapt to local conventions. It is developers who have to package things for users. A package that requires the user to even know of automake to install is broken.
When I installed on Linux, automake only appeared if I was compling from a tarball. Otherwise, RPM did whatever to install... but that forces distro makers to manage installation instead of the developer following a set of guidelines.
What issue are you talking about, specifically? I never have this problem you speak of, and I have not only lots and lots of free software installed, from my distro, from other distros and compiled by hand, but also proprietary software, and I have not seen this problem.
Also, automake can fail. Then what good is it? I've had it fail on more than one occasion.
Everything can fail. What's new?
In any case, a developer that considers automake as an user-level installation thingie is beyond help...
So what does Linux offer a developer to ask to OS where things should go? In.Net, there's the Environment.GetSpecialFolder, for example. But that's a Win32 API so it's not limited to.Net usage. Is there a similar API in Linux? Or do you just have to "know" where things should go, or rely on automake?
As I said, only a idiotic developer sees automake as an user level installation tool.
There are standard locations for essentially everything 95% of the software out there needs to install, and essentially everything 95% of the software out there needs to function is placed in standard locations. Developers need to be aware of the standard conventions (the LSB, for example), and that is not in any way different to needing to know the relevant.Net API.
If anything, this variety that annoys you forces people to build things on such a way that such reorganizations are possible. Automake, for example, is one outcome of that, and it achieves the amazing feat of allowing 97% of developers to simply not care about the issue of where things are to go in the final install. RPM and its build structure is similar, for different set of issues.
At least with Windows the number of locations to put things is smaller; system wide installs go to Program files. Configuration files get written to the user's profile. You can ask the OS what those locations are.
This is exactly the same for Linux, in any normal distro, for 95% of the software out there. The locations for `usual' stuff are completely normalized. If you have a non-system package that puts its stuff in odd places, then that is a bug in that software package, much as it is a bug in 50% of all windows apps not to look for "My Programs" using the OS-way, resulting in very sad messes because of localization and what not---not to speak of the debacle of UAC and the I-want-my-app-to-run-as-root-simply-because-I-do phenomenon.
Yes: you need to sometimes use a different packaging utility. For the standard user, that is irrelevant, as she will in most cases double click on the package and have the system do whatever is correct---this is just a matter of having the mime type associated with the proper app and, again, if your distro does not do this, it is a bug in your distro---and there is even PackageKit to abstract the innards and present a common interface to most common tasks.
In the end, people will do whatever they want, without absolutely any regard to `The Year of the Linux Desktop' strategists, who tend not to be the ones writing the code... And it is good that they do: doing exactly that it is how we got what we've got now, so I can but have very big hopes for what's to come.
I do not think that Linux should dominate the desktop. In fact, I think that's a rather absurd idea. What I think is that choice should be possible. I know what my choice is, too.
Also, I do not think that the masses identify Ubuntu with Linux. It really depends on what part of the `masses' you are in contact with.
And on top of that, I think you are underestimating the masses: if developers switch to $NEW_DISTRO, then the masses will follow. They are not idiots. For example, the `masses' that were using Linux before Ubuntu came to be were using something which was clearly not Ubuntu, and they were unidiotic enough to switch.
The fact that the possibility of better things exists is what keeps OSS going, despite what the moderators that saw my previous post as flamebait seem to think! I really cannot believe you can be at the same time an OSS suporter and think that attempts at building better things is bad.
Well: why did you buy hardware from a maker who does not consider making it usable for you important? I do not do that, and have not had trouble in about 10 years.
That is not true. You underestimate the significance of the idiots among `the board'. Most sensible persons will be happy to hear the platform has one more app available.
In the name of $DEITY, please get a distro which ships a Xorg server less that 5 years old: any such server can run with an empty xorg.conf file on 95% of configurations.
Since I'm required to use RTF at work, opening, editing, closing, and reopening to see if OO.o fucked up the RTF formatting again isn't an option. I'm not paid to waste time.
Well, you apparently are paid to work on a proprietary format (the myth that RTF is an open spec is only spread by those who have never tried to implement it, or by MS) I find it not surprising that applications developed without access to the required information to deal with that format cannot deal with that format in a perfect way...
What you need is not a word processor: you need a word processor which can do RTF according to the (non-existent) spec. Well, do not complain that OOo does not do that just as you do not complain that the GIMP is not good at saving RTF...
Why do you cat into a file and the use that as input, while you might simply echo into mysql?
I know spawning processes if fast nowadays, but things like
Slashdot Mirror
But Switzerland is filled with Swiss people, so the example hardly applies to other places...
Hmm, so what was the pantomime about weapons?
`switching between windows seems a lot better than on XP' is a sad, sad, observation.
You'd imagine people handling email for google knows you can use gmail with a different domain...
At the very most, it shows an attitude problem in me. I in no way represent any community whatsoever!
Have you tried to read the Illiad? There is more humanity in the couple of pages in which Patroclus dies, more thickness in the characters involved, than in the whole impressive stack of papers the script for the 6 movies must make.
Try it, really.
There are some interesting ideas in the original movies, specially the `used future' which someone remarks somewhere else in this thread, but as soon as you judge it from the point of view of someone who is not attached to the movies emotionally, the story is crap, the characters absurdly empty, the tension nil.
You watched AF1 more than once?!?!?!
Urgh. Sad days these are which have Star Wars as their Illiad!
I didn't mention releasing of source at all. Having the source or not is irrelevent to this topic, in my mind. Now releasing software, yes, it should be installable by someone on the target system.
It is relevant in so far you seem to consider that if someone releases the software in source form, it should be installable by end users. I, on the other hand, only consider software to be released to users when it is released in a way they can be expected to handle.
99% of Windows users will not be able to install software which is not packaged, and you clearly do not consider that as a fault in that platform. Why do you think that regular users not being to install software which was not packaged for them is a problem in the Linux platform (whatever that meay mean)?
I never said it was insurmountable, I said it throws up challanges needlessly. As a developer, I don't want to package my application 18 different ways. As a user, I want a single consistent way to install and manage my applications. It's an obsticle, and given that I had problems with it, I couldn't imagine say my sister not having problems. If you only get your software from your distribution supplier, I guess you'd be ok. The problem is that developers whose software DOESN'T get included have a problem of getting installed.
Your sister would never have that problem, because she is probably not even aware that there is another way to install software apart from nicely packaged packages trimed for their platform, whether that platform be Linux in some variant or Windows.
The IM client I was talking about was Kopete. And it wasn't that there was something wrong with the package, it was that the newest version would ONLY work with the newest libraries for KDE, which broke other applications on my system (once I satisfied the 30 or so dependencies I needed to update). It also broke some applications installed via automake.
But then you were trying to do something that even the Kopete developers did not intend users to do (I trust them enough to not take them for idiots). Clearly, they based their latest release on versions of libraries which are not yet common. They evidently did a release intended for integrators. Integrators should not have any problem setting up things and, in turn, packaging the package for end users.
If installing the newest KDE libs broke existing apps, then the new libs were not compatible with the old ones and therefore either they were intended to break compatibility (if that is the case, I am sure the KDE people have set things up so as to have parallel installability) or there is a major bug. In the second case, well, shit happens; in the first, then you must have done something wrong. You will say that is should be easier to do this correctly, but you should take into account that what you tired to do is change a basic library on which the whole desktop depends (if you are using KDE,at least), so that is a seriously major change to your system, which should be considered only when doing system-wide updates. And users simply do not do that.
Maybe things have improved, like I said. But that was my experience with Mandriva in 2006. After Linux on the desktop for five years, I finally threw up my hands in disgust with all the nonsense I had to go through whenever I tired to update my system or install new software, and it drove me to not only go back to Windows on the desktop, but to replace my long running Linux server.
Clearly, an example of YMMV.
Anyway, I'm not trying to bash Linux, but unless there have been signficiant updates, Linux has a long way to go in this area, and my claim that having too many distros / package managers is part of the reason. Take all the good ideas from each one, and make ONE that works really well, and make it part of the LSB. There is such a thing as "too much of a good thi
If they tell you that, then do not use their software. Consider it the analogue of a non-free-as-in-beer software developer charging you a billion dollars for their app: would you buy it at that price?
What are those two completely different ways you have inmind? You can't possibly mean `from sources' and `using package management'... The only reason you do not have this problematic alternative with non-OSS software is because you do not have the source! So you concede that exposing Automake to users is bad, and when I say that there's a lot of OSS software "installed" that way, and the other half is installed via a package management system, you quipe it's not a problem in Windows because I don't have the source? As a user, I don't care about the source. I just want the software that works. I don't care how a cow is milked, I just want to be able to drink the milk.No. I was just trying toguess what are these `two completely different ways of installing apps' you referred to but did not mention.
Right, because they are only given the option of installing software that's been packaged. Have any of your users found software that WASN'T packaged for their system, and wanted it installed? Have you had a user that found a package, but couldn't install it on Fedora because it was a deb package? As a developer, I've come across such things, and I'm not talking about development software either. IM clients, torrent cilents, etc.You seem to believe that someone releasing the source of some app should magically make it installable for anyone. That does not apply in the Linux world, because most people will have no idea of how to proceed, and it does not apply in the Window world, because of the same reason, and I'd say it does not apply in any world.
I consider `releasing an application' for users to mean `releasing it in user usable form'. That someone wrote an IM client and put the source somewhere in the internet is not releasing it in a user usable form. If the IM client developers simply puts the source out there, then he is not making it available for users. `User usable form' means packaged in a way users can use it. The developer may not care about doing it, but that is his prerrogative.
You should note that there is quite a lot of people who've somehow managed to get past this insurmountable amount of problems you keep talking about, commercial and non-commercial, open-source and non-open source. It surely could be easier (but I would not want to use an internet-facing IM client written by a developer who cannot grok the rpm .spec format...), but as usual, every could be easier.
Then complain to the developers of those OSS projects. You do understand that no one is in a position to tell every OSS developer (whatever that may mean!) to stop being a fool and provide a sensible way for their app to be installed.
What issue are you talking about, specifically? I never have this problem you speak of, and I have not only lots and lots of free software installed, from my distro, from other distros and compiled by hand, but also proprietary software, and I have not seen this problem. Well the fact that there are at least two completely different ways to install software on Linux doesn't help. The fact that each distro seems to create their very own package management amplifies the problem.What are those two completely different ways you have inmind? You can't possibly mean `from sources' and `using package management'... The only reason you do not have this problematic alternative with non-OSS software is because you do not have the source!
It does not matter what package management a distro picks: if it is a user-oriented distro, and it is good at that, then the user will have absolutely no interaction with the package tools apart from pointing, clicking, and so on. I know absolutely computer-illiterate people who from time to time install apps on Ubuntu and Fedora, and who do not know that the underlying packaging systems are different.
What you are complaining is about half-finished attempts at interfaces to packaging systems. But the variety of packaging systems is irrelevant to your problem: your problem lies entirely with the `half-finished' part. Again: what's new?
Everything can fail. What's new? Automake or even RPM installations have failed for me many more times than installtion of programs on Windows. Windows has an entire API available to developers to consistently install programs. Why isn't there such a thing in Linux?Well, from the developer's point of view, RPM is an API. So is the debian packaging format.
You have had failures installing, I haven't in ages (at least, since I left Slackware, which characteristically has a utmostly primitive pacaging system) What problems have you had? With what packages? How can you possibly tell it is not the developer's fault instead of the package format's, and that they would not have screwed up using any other API?
There are standard locations for essentially everything 95% of the software out there needs to install, and essentially everything 95% of the software out there needs to function is placed in standard locations. Developers need to be aware of the standard conventions (the LSB, for example), and that is not in any way different to needing to know the relevantWhat files? Why are apps dependent on where those files are?
Do you know that an RPM file does not have hard-coded the locations where its files will be put, but instead at rpm-installation time the rpm program reads a configuration file which tells it where the different pieces should go? And that it is trivial to install a rpm in a debian box configured to have it follow the debian standards? I am quite sure dpkg allows fore exactly the same.
Of course! But automake makes it trivial for the developers/distributors to adapt to local conventions. It is developers who have to package things for users. A package that requires the user to even know of automake to install is broken.
When I installed on Linux, automake only appeared if I was compling from a tarball. Otherwise, RPM did whatever to install... but that forces distro makers to manage installation instead of the developer following a set of guidelines.What issue are you talking about, specifically? I never have this problem you speak of, and I have not only lots and lots of free software installed, from my distro, from other distros and compiled by hand, but also proprietary software, and I have not seen this problem.
Also, automake can fail. Then what good is it? I've had it fail on more than one occasion.Everything can fail. What's new?
In any case, a developer that considers automake as an user-level installation thingie is beyond help...
So what does Linux offer a developer to ask to OS where things should go? InAs I said, only a idiotic developer sees automake as an user level installation tool.
There are standard locations for essentially everything 95% of the software out there needs to install, and essentially everything 95% of the software out there needs to function is placed in standard locations. Developers need to be aware of the standard conventions (the LSB, for example), and that is not in any way different to needing to know the relevant .Net API.
If anything, this variety that annoys you forces people to build things on such a way that such reorganizations are possible. Automake, for example, is one outcome of that, and it achieves the amazing feat of allowing 97% of developers to simply not care about the issue of where things are to go in the final install. RPM and its build structure is similar, for different set of issues.
At least with Windows the number of locations to put things is smaller; system wide installs go to Program files. Configuration files get written to the user's profile. You can ask the OS what those locations are.This is exactly the same for Linux, in any normal distro, for 95% of the software out there. The locations for `usual' stuff are completely normalized. If you have a non-system package that puts its stuff in odd places, then that is a bug in that software package, much as it is a bug in 50% of all windows apps not to look for "My Programs" using the OS-way, resulting in very sad messes because of localization and what not---not to speak of the debacle of UAC and the I-want-my-app-to-run-as-root-simply-because-I-do phenomenon.
Yes: you need to sometimes use a different packaging utility. For the standard user, that is irrelevant, as she will in most cases double click on the package and have the system do whatever is correct---this is just a matter of having the mime type associated with the proper app and, again, if your distro does not do this, it is a bug in your distro---and there is even PackageKit to abstract the innards and present a common interface to most common tasks.
In the end, people will do whatever they want, without absolutely any regard to `The Year of the Linux Desktop' strategists, who tend not to be the ones writing the code... And it is good that they do: doing exactly that it is how we got what we've got now, so I can but have very big hopes for what's to come.
I do not think that Linux should dominate the desktop. In fact, I think that's a rather absurd idea. What I think is that choice should be possible. I know what my choice is, too.
Also, I do not think that the masses identify Ubuntu with Linux. It really depends on what part of the `masses' you are in contact with.
And on top of that, I think you are underestimating the masses: if developers switch to $NEW_DISTRO, then the masses will follow. They are not idiots. For example, the `masses' that were using Linux before Ubuntu came to be were using something which was clearly not Ubuntu, and they were unidiotic enough to switch.
The fact that the possibility of better things exists is what keeps OSS going, despite what the moderators that saw my previous post as flamebait seem to think! I really cannot believe you can be at the same time an OSS suporter and think that attempts at building better things is bad.
So the prospect that there will be something better in the future is bad now?
I do not know what MS is doing to the masses, but surely the training works!
So is ATI hardware ready for the desktop? Apparently they cannot write a working driver... and not only they have the specs: they wrote the specs!
Well: why did you buy hardware from a maker who does not consider making it usable for you important? I do not do that, and have not had trouble in about 10 years.
The density of information you can achieve using a keyboard is going to be very hard to beat using motion capture or voice recognition.
With Linux, a person could make some money installing drivers, software, printers, etc. for people.
And that is different from Windows or OSX how, exactly?
(99% kidding...)Then there is hope that one day the details will be fixed into a not so ugly state, without needing a complete rewrite!
That is not true. You underestimate the significance of the idiots among `the board'. Most sensible persons will be happy to hear the platform has one more app available.
In the name of $DEITY, please get a distro which ships a Xorg server less that 5 years old: any such server can run with an empty xorg.conf file on 95% of configurations.
Well, you apparently are paid to work on a proprietary format (the myth that RTF is an open spec is only spread by those who have never tried to implement it, or by MS) I find it not surprising that applications developed without access to the required information to deal with that format cannot deal with that format in a perfect way...
What you need is not a word processor: you need a word processor which can do RTF according to the (non-existent) spec. Well, do not complain that OOo does not do that just as you do not complain that the GIMP is not good at saving RTF...
Why do you cat into a file and the use that as input, while you might simply echo into mysql? I know spawning processes if fast nowadays, but things like
someprocess | cat > somefilejust saddens me!
It ceases not to amaze me to find comments like this which are based on faith on a miraculous correlation between slashdot user id and something.
I think we all become dumber just for having read such idiocy...