I disagree. I think the real problem is that many developers, administrators, and users don't like the idea of trusting an application to install itself correctly on a system....
Autopackage allows one to install a package without a root password, so it must install it in the home directory, thereby avoiding any conflict with existing files. I'm not aware of any mechanism that rpm or yum has to automatically detect 'tampering' of already-installed files (such as through a worm or virus). I'm not aware of any measures autopackage takes to ensure that a package is not a virus or spyware, but in theory they could have developers register in a 'trusted packages' list that autopackage would ping each time a user tried to install a package. Then if the package isn't from a 'trusted source' than a dialogue would pop up to warn the user of potential danger associated with installing this package. Then of course, there is the probelm of statically linked libraries. There does seem to be a potential security issue with that, and it would be more of a hassle for the user to update all his apps to plug a security hole. Then again, autopackage could hold a database with a list of all installed libraries across all installed apps, and then one could download a.package file and have it update all instances of X library. Autopackage doesn't have update abilities yet, but in the future his may become a possibility.
You can double click a rpm file and have it install itself, but it requires the root password to do so, and it doesn't handle dependencies like autopackage does.
Really, the three major advantages that autopackage has are cross-platform compatiblity with other distros, the resolution of dependencies without being required to go to yum or Synaptic, and faster distribution of software among different distros (one doesn't have to wait for their repos to be updated with the package, one can just go to the developer's web site and install it from their.package file, regardless of their distro). The ability to just click on a.package file and have it install itself and any dependencies is a big advantage. But autopackage also lacks things that rpm and deb has, and so autopackage isn't a replacement for rpms or debs, but rather a partner with them to make installing certain pieces of software easier.
Autopackage has a few hurdles it needs to overcome.
First is user acceptance. There are those that prefer a central repository for all their software needs, rather than going through the 'hassle' of navigating to the developers website, and they will be very vocal about this autopackage 'downside'. I've seen these arguments myself, so there is no doubt in my mind that this is a hurdle for Autopackage.
Second is developer acceptance and support. This is the same as you said, but with an added clause. When developers use autopackage, they need to advertise it as the optimal choice for users browsing their website. Looking at the list of software projects using autopackage on the autopackage website, there are some high-profile projects using autopackage, but it isn't advertised nearly enough on those projects' websites that they use autopackage. This contributes to autopackage's status as an obscure software project. What developers should do is advertise their autopackage on their website most prominently, and leave the rpms and debs to repositories. That way, those using repos are set, and those using autopackage are set, and autopackage will gain more acceptance as more people use it and realize its usefulness.
Third is vendor acceptance. When distros start advocating autopackages then they will take off. Autopackage isn't meant to be a replacement for central repositories of rpm or deb files, it's meant augment the user-friendliness of the central repositories with non-central-yet-easier-to-use-for-some repositories. It's also meant to be easier for developers to use, since it allows them to make one package that will work on all GNU/Linux distros. I'm not sure whether the Autopackage devs plan to make Autopackage compete with rpms and debs in the future, but if they made it possible to create central repositories of autopackages similar to rpm and deb repos, then it would give users a choice between non-central repos (for less tech-savvy users) and central repos (for more tech-savvy users). This could also spur distro vendors to advocate the use of autopackages more. Of course, that would be an ideal and as we have seen, many distros have invested to much into their way of doing things to consider a new and possibly better way of managing packages.
Personally, I put folders on my desktop. I don't want to navigate into my home folder and then to the music folder. Just give me music. I have been thinking about using the 'Places' bar in GNOME, but I still think it is better to have my folders on my desktop.
Since it's rampant, the only thing dying is the artist's hope of actually seeing a little compensation for your enjoyment of her work. Does your idea of "fair use" include making that artist your personal little entertainment slave?
I'm certainly in favor of making her my entertainment slave.
Yes, and? That's free music. If you have some distaste for vg music simply because it's vg music, then you're missing out on some good stuff.
On ocremix.org, look up The Ken Song (Street Fighter 2) and maybe some of the FF or Crono Trigger music. Look up anything by Ailsean. Look up Forlorn Dreams by Ryan8Bit on vgmix.com.
There is so much variety on both of these sites, you can't help but find SOMETHING in there that you like. Rap? Rock? Trance? Techno? Orchestral? You want something that sounds weird? Look up Children of the Monkey Machine. His stuff will creep you out.
All I'm saying is don't knock it until you try it out. Since it's free, the only thing you have to lose is 30 minutes browsing and downloading various songs.
I'll still care about what OS I have, and my OS will not be obsolete or fade into obscurity.
Oh, and don't forget about those people out there that would rather not rely on one source for all of their content/tools (even if for now the source is not evil).
Actually, you can get free music from ocremix.org and vgmix.com. Ocremix was on slashdot a while back, it got some negative comments about copyrights; however, there isn't actually any problem with copyrights with remixing vg songs (fair-use and all). 99.9% of the songs I listen to come from these two sources; I'm quite happy with the quality.
That's funny because if I remember correctly, Ancient Israel was around for 1000+ years whilst also having the laws of the 'corner of the field'. I don't think it harmed the farmers too much.
So how long does a species of animal (or race of people) need to live somewhere before they 'belong there'? Jeez, the Kiore rats have been there over 1000 years!
Yes, it seems that letting CentOS exist has made it difficult for Redhat to compete. Same with Novell and Suse. Don't forget Mandriva. Those companies seem to be very short-sighted, and they obviously haven't considered that they're shooting themselves in the foot (although, Mandriva did gain popularity through bring free...).
The college kid is doing what he is doing for free, on what free time he has after studying and social activities and video games. The guy competing against him in X business is being paid to work 8 hours or more a day to make software. I wouldn't say that the college kid exactly has the advantage here. You want to compete? DO A BETTER JOB.
Some of the lessened market demand can be traced straight back to free software.
Really? Where do you get that from? Empirical evidences shows that one can get very good jobs from large companies if one of those companies sees the quality in your work. How many times have we heard "X lead programmer for large Free Software project was hired by Y large enterprise"? You have nothing to back up your statement except, what you believe to be, a logical argument. There are many factors which can effect the decrease of programmer jobs in America, why pick a reason which has evidence that contradicts your conclusion?
Slashdot Mirror
You forgot:
11. Profit!!!
What do I win?
I disagree. I think the real problem is that many developers, administrators, and users don't like the idea of trusting an application to install itself correctly on a system....
.package file and have it update all instances of X library. Autopackage doesn't have update abilities yet, but in the future his may become a possibility.
.package file, regardless of their distro). The ability to just click on a .package file and have it install itself and any dependencies is a big advantage. But autopackage also lacks things that rpm and deb has, and so autopackage isn't a replacement for rpms or debs, but rather a partner with them to make installing certain pieces of software easier.
Autopackage allows one to install a package without a root password, so it must install it in the home directory, thereby avoiding any conflict with existing files. I'm not aware of any mechanism that rpm or yum has to automatically detect 'tampering' of already-installed files (such as through a worm or virus). I'm not aware of any measures autopackage takes to ensure that a package is not a virus or spyware, but in theory they could have developers register in a 'trusted packages' list that autopackage would ping each time a user tried to install a package. Then if the package isn't from a 'trusted source' than a dialogue would pop up to warn the user of potential danger associated with installing this package. Then of course, there is the probelm of statically linked libraries. There does seem to be a potential security issue with that, and it would be more of a hassle for the user to update all his apps to plug a security hole. Then again, autopackage could hold a database with a list of all installed libraries across all installed apps, and then one could download a
You can double click a rpm file and have it install itself, but it requires the root password to do so, and it doesn't handle dependencies like autopackage does.
Really, the three major advantages that autopackage has are cross-platform compatiblity with other distros, the resolution of dependencies without being required to go to yum or Synaptic, and faster distribution of software among different distros (one doesn't have to wait for their repos to be updated with the package, one can just go to the developer's web site and install it from their
I may be interested in spreading the word. Email me at mijokijo@gmail.com and tell me more.
Autopackage has a few hurdles it needs to overcome.
First is user acceptance. There are those that prefer a central repository for all their software needs, rather than going through the 'hassle' of navigating to the developers website, and they will be very vocal about this autopackage 'downside'. I've seen these arguments myself, so there is no doubt in my mind that this is a hurdle for Autopackage.
Second is developer acceptance and support. This is the same as you said, but with an added clause. When developers use autopackage, they need to advertise it as the optimal choice for users browsing their website. Looking at the list of software projects using autopackage on the autopackage website, there are some high-profile projects using autopackage, but it isn't advertised nearly enough on those projects' websites that they use autopackage. This contributes to autopackage's status as an obscure software project. What developers should do is advertise their autopackage on their website most prominently, and leave the rpms and debs to repositories. That way, those using repos are set, and those using autopackage are set, and autopackage will gain more acceptance as more people use it and realize its usefulness.
Third is vendor acceptance. When distros start advocating autopackages then they will take off. Autopackage isn't meant to be a replacement for central repositories of rpm or deb files, it's meant augment the user-friendliness of the central repositories with non-central-yet-easier-to-use-for-some repositories. It's also meant to be easier for developers to use, since it allows them to make one package that will work on all GNU/Linux distros. I'm not sure whether the Autopackage devs plan to make Autopackage compete with rpms and debs in the future, but if they made it possible to create central repositories of autopackages similar to rpm and deb repos, then it would give users a choice between non-central repos (for less tech-savvy users) and central repos (for more tech-savvy users). This could also spur distro vendors to advocate the use of autopackages more. Of course, that would be an ideal and as we have seen, many distros have invested to much into their way of doing things to consider a new and possibly better way of managing packages.
Personally, I put folders on my desktop. I don't want to navigate into my home folder and then to the music folder. Just give me music. I have been thinking about using the 'Places' bar in GNOME, but I still think it is better to have my folders on my desktop.
Since it's rampant, the only thing dying is the artist's hope of actually seeing a little compensation for your enjoyment of her work. Does your idea of "fair use" include making that artist your personal little entertainment slave?
I'm certainly in favor of making her my entertainment slave.
I don't know how to tell you this, but... I think that was the point of the article.
I suppose this is just a matter of categories that are too specific, with YRO being the closest to the intended category.
I think perhaps our definitions of 'dynamic' are different.
I hear that old Koreans seem to care deeply for soviet Russia...
Not my mom's...no sir, her's smell like a bed of roses.
1. Buy world map service
2. Release it for free
3. ???
4. Burma Shave
Yes, and? That's free music. If you have some distaste for vg music simply because it's vg music, then you're missing out on some good stuff.
On ocremix.org, look up The Ken Song (Street Fighter 2) and maybe some of the FF or Crono Trigger music. Look up anything by Ailsean. Look up Forlorn Dreams by Ryan8Bit on vgmix.com.
There is so much variety on both of these sites, you can't help but find SOMETHING in there that you like. Rap? Rock? Trance? Techno? Orchestral? You want something that sounds weird? Look up Children of the Monkey Machine. His stuff will creep you out.
All I'm saying is don't knock it until you try it out. Since it's free, the only thing you have to lose is 30 minutes browsing and downloading various songs.
- A Full-fledged Word Processor/Spreadsheet
- Full-fledged Image manipulators (vector, raster, 3D)
- An IM client
- Lots of games
- IDE for any [or all] languages
- Various other niche-market software
I'll still care about what OS I have, and my OS will not be obsolete or fade into obscurity.Oh, and don't forget about those people out there that would rather not rely on one source for all of their content/tools (even if for now the source is not evil).
Actually, you can get free music from ocremix.org and vgmix.com. Ocremix was on slashdot a while back, it got some negative comments about copyrights; however, there isn't actually any problem with copyrights with remixing vg songs (fair-use and all). 99.9% of the songs I listen to come from these two sources; I'm quite happy with the quality.
Since when did Wikipedia stop being an encyclopedia and became a directory for music lyrics and reviews?
That's funny because if I remember correctly, Ancient Israel was around for 1000+ years whilst also having the laws of the 'corner of the field'. I don't think it harmed the farmers too much.
So how long does a species of animal (or race of people) need to live somewhere before they 'belong there'? Jeez, the Kiore rats have been there over 1000 years!
Was it a team of AC's?
Since when did they put Opera under a Free license?
Who needs these? I thought 640...I mean, 6800 was all anybody needed?
I don't know, ask Microsoft why they hired the founder of Gentoo. You might also want to ask the guys at Nokia why they hired this guy http://mobile.newsforge.com/mobility/05/06/08/1948 202.shtml?tid=97&tid=2 . You might also want to find out why Red Hat develops Free Software actively.
You're free to disagree, but you're ignoring the evidence which directely contradicts your point.
Yes, it seems that letting CentOS exist has made it difficult for Redhat to compete. Same with Novell and Suse. Don't forget Mandriva. Those companies seem to be very short-sighted, and they obviously haven't considered that they're shooting themselves in the foot (although, Mandriva did gain popularity through bring free...).
The college kid is doing what he is doing for free, on what free time he has after studying and social activities and video games. The guy competing against him in X business is being paid to work 8 hours or more a day to make software. I wouldn't say that the college kid exactly has the advantage here. You want to compete? DO A BETTER JOB.
Some of the lessened market demand can be traced straight back to free software.
Really? Where do you get that from? Empirical evidences shows that one can get very good jobs from large companies if one of those companies sees the quality in your work. How many times have we heard "X lead programmer for large Free Software project was hired by Y large enterprise"? You have nothing to back up your statement except, what you believe to be, a logical argument. There are many factors which can effect the decrease of programmer jobs in America, why pick a reason which has evidence that contradicts your conclusion?
How...did...this...get...insightful?