Is that by convention or by law? In the US employment is voluntary. You don't HAVE to give any notice at all, but it's considered professional to do so.
Your example is exactly why giving notice is not something you really do anymore. I got further screwed. I was nice like you and did all that, then HR came back with a letter, "All vacation is canceled" you cant take vacation after you give notice, you also forfeit all vacation and sick time accrued.
I thought by law they had to pay you for any vacation time earned. At the very least, if that's what they put in their manual, it IS illegal. Whatever you put in your employee manual becomes legally binding.
Ok, so how do you prove to your bank it was you? Should every company require DNA samples? That wouldn't even work... so.. how do you prove someone is who they say they are. You act as if all this paperwork that everyone requires means something.
My sister's brother was offically dead since birth. The doctor wanted to go on vacation, and filled out both the birth and death certificates, leaving the nurse to decide which one to enter a time on and file. Guess which one the nurse filed? It wasn't until his twenties he was able to "prove" to the government he was alive!
Well I meant the attitude that they consider it "released" when they throw up a tarball with automake. Anyway, I hope you don't think I'm bashing Linux for the sake of bashing. I think this (and other things) are ligitment problems holding it back from wider adoption. Unfortunatly many times the community just flat out refuses to acknowledge the problem, even though their users are insisting it is a problem.
I find that attitute more than anything to keep me from wanting to try Linux again; when my users say something doesn't work for them, it just doesn't work for them, and I need to find out a way that will.
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.
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.
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)?
99% of Windows software is packaged and not claimed to be released without some kind of installation package. My whole point is that maybe if linux finally settled on ONE way to manage application installations, more developers would ensure to package their software. As it is, there are a huge number of applications which don't have any kind of packaging beyond automake, and it doesn't seem to be getting better. Developers targeting Windows though wouldn't even dream of NOT making an MSI package. So yes, it's a platform problem.
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.
That's just silly. It's not possible for her to find software she would like to install, and be confronted with the choice between tgz (whatever that is, she'll think) or RPM (which notes that it's for Redhat, which she's not running). I know I was hit with that; went looking for some software to fill a need, found it, and because I know what a tgz was able to go that route, although with the problems I mentioned. To say it won't happen is denying reality.
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.
Except that they also said the only fix to the problems Kopete was having was to upgrade. Not trivial problems, problems of not being able to connect at all to MSN or Yahoo, when they were changnig the protocol almost daily. So they WERE telling people to upgrade. So what is a normal user (or me) supposed to do? Wait a few months until Mandriva releases a new version, and just not have IM?
That instance shows that package management is broken (because I had to do all the work of finding the OTHER updates) and that Linux isn't immune to DLL hell either.
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.
I can't tell you why it broke. It should not have happened either way. I install
It depends on the changes required by the ISO to approve the standard. They may not be trival. Also, a way to conver the older format to the new one is needed, everything needs LOTS of testing, oh and I don't think they had developers sitting on their hands waiting for the ISO to finish their changes so they could "get right on that."
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?
Let's put the upper level more realistic for an end user; $400. Yeah, I'd pay that. If it was an application that targeted commerical tasks, say Photoshop, yes I'd pay more. At the end of the day, I need software I can use, so software that is difficult to install isn't useful.
No. I was just trying toguess what are these `two completely different ways of installing apps' you referred to but did not mention.
Sorry, I should have been more clear.
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 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. Which is the problem with the number of Linux distros; typically the target system is tied to a particular package manager. Hopefully things have changed an RPMs can be used on debs and debs on RPM systems without change or knowledge of the format by the user; ideally the LSB would standardize on the best one. On Windows, you have the Windows Installer API, and that's it. Easy for developers and end users.
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.
The IM client was packaged as an RPM though.. which didn't help, because of the problems I mentioned.
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.
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.
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.
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.
Anyway, I'm not trying to bash Linux, but unless there have been signficiant updates, Linux has a long way to go in t
No, irrational is believing that people don't lie. It's also irrational to believe that people don't change, and that they can't possibly change for the worse. Any rational person understands that, and so doesn't hold someone to their "solemn word" to be together "forever." You are right though; there's no reason to continue this. You'll eithe figure it out one day, or you'll murder you wife to get yourself out of the twisted notions of love that you have.
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.
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.
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.
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.
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.
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?
It becomes relevent when I put on my developer hat and need to figure out how to package my software. Do I choose RPM, DEP, this new package format? I need to create a package for all three? At this point I WOULD consider releasing just an Automake "installation," just so I don't have to package my software a hundred different ways. This is the point I'm trying to make and that is why I think developers release tarballs with an automake install.
Well, from the developer's point of view, RPM is an API. So is the debian packaging format.
Really? I can write a code module and plug it in? Maybe just be inheriting a class? In.Net that's how I can plug custom code into an installer. It's actually part of my assembly. In Linux, deployment seems totally seperated from development. I wouldn't say RPM is an API so much as it is a container format which is created by running a command line program.
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?
You totally missed my point. Ya, it's partially the developers fault, because they didn't create their installer properly. It's also the platforms fault, because package management is not part of every single Linux setup. There's no standard way for your package to see if another one is installed; there's no standard way for a developer to upgrade an existing package. So that when I simply tried to upgrade the Kopete package, for example, it just said "no." I had to dig out the relevent upgrades. Which weren't packaged by Redhat y
What utter nonsense. People change, and failing to reconize that is stupidity. My parents divorced and I still trust them. Aso do their new signficant others, and they are both very happy. No one is perfect, and people lie. As I said, you're living in a delusional dream world.
Divorce is only causes unhappines because of the arbtrary rules and government sticking it's nose in and keeping conceps like alimony alive. If it were easier to people to end a marriage, I say people would be happier overall. You seriously underestimate the number of people that are miserable because they are in a marriage they can't leave; either because they think it's better for the kids (it's not) or because of the finanical consequences forced on by a society that shouldn't even be involved in the private affairs of two individuals.
Wake up from your delusion, before your mind snaps when you are forced to realize your picture of the world is not how things are, or can ever be.
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.
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.
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?
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?
But they aren't raising awareness. Anything they say is written off as "oh, those screwjobs at Greenpeace are yelling about some nonsense again." And that's pretty much as far as it goes. So they aren't raising awareness, they come off like a bunch of crazed monkies to be ignored. Worse, it associates enviornmentalism with crazed monkies, so that whenever the subject comes up at all, people are more dismissive.
Yes, everything you said is correct. One detail that is missing though is that given the choice between burning stored energy by destroying fat or muscle, the body would much rather use the energy it just got from what you ate. That's why you need a caloric deficate to burn fat.
Going back to the OP's biker friend, yes his muscles may be a bit larger than most, but, assuming he bikes and doesn't do a whole lot of other things (like heavy resistence training) the biker won't need much more than an average person on a regular day.
The OP was asserting that his friend needed to significantly eat more every day of his life, whether he biked or not, just to maintain his body weight. I was trying to point out that wasn't true. For body builders it would be, but even then they would eat only a little more to maintain on rest days.
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.
The thing is, automake shouldn't be seen by an end user. 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. Also, automake can fail. Then what good is it? I've had it fail on more than one occasion.
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.
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?
No, propaganda is useless, because it's always done with a spin, half truths, and outlight lies, all mixed into one. The danger is that a legitimate concern may now be ignored because those opposed to tougher enviornment standards will point out all the lies and half truths. When you need to lie to make your point, people tend to think you have something to hide and are trying to trick them.
No, it's not that something better may come along. The problem would be that it is just different enough to break everything. Redhat puts it's files in one location; Ubuntu another. Slack another. Each one of these differences need to be accounted for by developers. That means things are more likely to break when trying to use software built on redhat on slack. You can't even take the installer packages from RH to Ubuntu.. so now i have to go and find the same program again, just in a different package format. If there is even one of the system you're running at the time.
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.
Well, they even concede that the malware may have gotten onto the computer because the user let it. No system will protect someone with admin access to the machine from compromising the computer if that user chooses.
The article is pretty useless; they even complain that the MS Malware Removal Tool doesn't remove all malware... well duh, it was never designed to and it's not supposed to replace actualy anti-virus or anti-malware software. It's supposed to catch common and easily fixed malware.
No it didn't. As I white, I could sit anywhere I wanted on a bus. How did that negatively affect white people?
But I don't and I didn't. Time for me to stop reading your post right there, troll.
That's rich, considering what you've posted thus far. Any reasonable person can see that you hate gays, for whatever reason. I guess when called out and backed into a corner, the bigot troll has to run and hide, hoping not to be seen in other threads.
Well, if it becomes the Next Big Thing, it will continue the perception to many that you shouldn't switch to Linux, because eventually another new distro flavor of the month will come along and what you have now work work quite right.
Slashdot Mirror
Is that by convention or by law? In the US employment is voluntary. You don't HAVE to give any notice at all, but it's considered professional to do so.
Your example is exactly why giving notice is not something you really do anymore. I got further screwed. I was nice like you and did all that, then HR came back with a letter, "All vacation is canceled" you cant take vacation after you give notice, you also forfeit all vacation and sick time accrued.
I thought by law they had to pay you for any vacation time earned. At the very least, if that's what they put in their manual, it IS illegal. Whatever you put in your employee manual becomes legally binding.
Opps. That should be wife, not sister.
Hmm.. never even occurred to me either. Thanks for coming back and throwing that out there though too.
Ok, so how do you prove to your bank it was you? Should every company require DNA samples? That wouldn't even work... so.. how do you prove someone is who they say they are. You act as if all this paperwork that everyone requires means something.
My sister's brother was offically dead since birth. The doctor wanted to go on vacation, and filled out both the birth and death certificates, leaving the nurse to decide which one to enter a time on and file. Guess which one the nurse filed? It wasn't until his twenties he was able to "prove" to the government he was alive!
Well I meant the attitude that they consider it "released" when they throw up a tarball with automake. Anyway, I hope you don't think I'm bashing Linux for the sake of bashing. I think this (and other things) are ligitment problems holding it back from wider adoption. Unfortunatly many times the community just flat out refuses to acknowledge the problem, even though their users are insisting it is a problem.
I find that attitute more than anything to keep me from wanting to try Linux again; when my users say something doesn't work for them, it just doesn't work for them, and I need to find out a way that will.
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.
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.
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)?
99% of Windows software is packaged and not claimed to be released without some kind of installation package. My whole point is that maybe if linux finally settled on ONE way to manage application installations, more developers would ensure to package their software. As it is, there are a huge number of applications which don't have any kind of packaging beyond automake, and it doesn't seem to be getting better. Developers targeting Windows though wouldn't even dream of NOT making an MSI package. So yes, it's a platform problem.
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.
That's just silly. It's not possible for her to find software she would like to install, and be confronted with the choice between tgz (whatever that is, she'll think) or RPM (which notes that it's for Redhat, which she's not running). I know I was hit with that; went looking for some software to fill a need, found it, and because I know what a tgz was able to go that route, although with the problems I mentioned. To say it won't happen is denying reality.
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.
Except that they also said the only fix to the problems Kopete was having was to upgrade. Not trivial problems, problems of not being able to connect at all to MSN or Yahoo, when they were changnig the protocol almost daily. So they WERE telling people to upgrade. So what is a normal user (or me) supposed to do? Wait a few months until Mandriva releases a new version, and just not have IM?
That instance shows that package management is broken (because I had to do all the work of finding the OTHER updates) and that Linux isn't immune to DLL hell either.
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.
I can't tell you why it broke. It should not have happened either way. I install
It depends on the changes required by the ISO to approve the standard. They may not be trival. Also, a way to conver the older format to the new one is needed, everything needs LOTS of testing, oh and I don't think they had developers sitting on their hands waiting for the ISO to finish their changes so they could "get right on that."
Why shouldn't they support both formats?
Well, ok then. But not twitter. He's a jerk, even for a troll.
Please don't feed the trolls.
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?
.spec format...), but as usual, every could be easier.
Let's put the upper level more realistic for an end user; $400. Yeah, I'd pay that. If it was an application that targeted commerical tasks, say Photoshop, yes I'd pay more. At the end of the day, I need software I can use, so software that is difficult to install isn't useful.
No. I was just trying toguess what are these `two completely different ways of installing apps' you referred to but did not mention.
Sorry, I should have been more clear.
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 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. Which is the problem with the number of Linux distros; typically the target system is tied to a particular package manager. Hopefully things have changed an RPMs can be used on debs and debs on RPM systems without change or knowledge of the format by the user; ideally the LSB would standardize on the best one. On Windows, you have the Windows Installer API, and that's it. Easy for developers and end users.
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.
The IM client was packaged as an RPM though.. which didn't help, because of the problems I mentioned.
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
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.
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.
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.
Anyway, I'm not trying to bash Linux, but unless there have been signficiant updates, Linux has a long way to go in t
No, irrational is believing that people don't lie. It's also irrational to believe that people don't change, and that they can't possibly change for the worse. Any rational person understands that, and so doesn't hold someone to their "solemn word" to be together "forever." You are right though; there's no reason to continue this. You'll eithe figure it out one day, or you'll murder you wife to get yourself out of the twisted notions of love that you have.
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.
.Net that's how I can plug custom code into an installer. It's actually part of my assembly. In Linux, deployment seems totally seperated from development. I wouldn't say RPM is an API so much as it is a container format which is created by running a command line program.
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.
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.
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.
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.
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?
It becomes relevent when I put on my developer hat and need to figure out how to package my software. Do I choose RPM, DEP, this new package format? I need to create a package for all three? At this point I WOULD consider releasing just an Automake "installation," just so I don't have to package my software a hundred different ways. This is the point I'm trying to make and that is why I think developers release tarballs with an automake install.
Well, from the developer's point of view, RPM is an API. So is the debian packaging format.
Really? I can write a code module and plug it in? Maybe just be inheriting a class? In
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?
You totally missed my point. Ya, it's partially the developers fault, because they didn't create their installer properly. It's also the platforms fault, because package management is not part of every single Linux setup. There's no standard way for your package to see if another one is installed; there's no standard way for a developer to upgrade an existing package. So that when I simply tried to upgrade the Kopete package, for example, it just said "no." I had to dig out the relevent upgrades. Which weren't packaged by Redhat y
What utter nonsense. People change, and failing to reconize that is stupidity. My parents divorced and I still trust them. Aso do their new signficant others, and they are both very happy. No one is perfect, and people lie. As I said, you're living in a delusional dream world.
Divorce is only causes unhappines because of the arbtrary rules and government sticking it's nose in and keeping conceps like alimony alive. If it were easier to people to end a marriage, I say people would be happier overall. You seriously underestimate the number of people that are miserable because they are in a marriage they can't leave; either because they think it's better for the kids (it's not) or because of the finanical consequences forced on by a society that shouldn't even be involved in the private affairs of two individuals.
Wake up from your delusion, before your mind snaps when you are forced to realize your picture of the world is not how things are, or can ever be.
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.
.Net API.
Yet for many OSS projects, this is the only want to install.
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.
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?
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
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?
Sorry, you're delusional if you think marriage is forever and that no matter what the other spouse does they should be "unconditionally loved."
In real life, we allow for divorces, in some cases for reasons as simple as the couple can't get along anymore.
Who are you to force two people to stay together that no longer with to? That is real life.
But they aren't raising awareness. Anything they say is written off as "oh, those screwjobs at Greenpeace are yelling about some nonsense again." And that's pretty much as far as it goes. So they aren't raising awareness, they come off like a bunch of crazed monkies to be ignored. Worse, it associates enviornmentalism with crazed monkies, so that whenever the subject comes up at all, people are more dismissive.
Yes, everything you said is correct. One detail that is missing though is that given the choice between burning stored energy by destroying fat or muscle, the body would much rather use the energy it just got from what you ate. That's why you need a caloric deficate to burn fat.
Going back to the OP's biker friend, yes his muscles may be a bit larger than most, but, assuming he bikes and doesn't do a whole lot of other things (like heavy resistence training) the biker won't need much more than an average person on a regular day.
The OP was asserting that his friend needed to significantly eat more every day of his life, whether he biked or not, just to maintain his body weight. I was trying to point out that wasn't true. For body builders it would be, but even then they would eat only a little more to maintain on rest days.
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.
.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?
The thing is, automake shouldn't be seen by an end user. 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. Also, automake can fail. Then what good is it? I've had it fail on more than one occasion.
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.
So what does Linux offer a developer to ask to OS where things should go? In
No, propaganda is useless, because it's always done with a spin, half truths, and outlight lies, all mixed into one. The danger is that a legitimate concern may now be ignored because those opposed to tougher enviornment standards will point out all the lies and half truths. When you need to lie to make your point, people tend to think you have something to hide and are trying to trick them.
No, it's not that something better may come along. The problem would be that it is just different enough to break everything. Redhat puts it's files in one location; Ubuntu another. Slack another. Each one of these differences need to be accounted for by developers. That means things are more likely to break when trying to use software built on redhat on slack. You can't even take the installer packages from RH to Ubuntu.. so now i have to go and find the same program again, just in a different package format. If there is even one of the system you're running at the time.
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.
Well, they even concede that the malware may have gotten onto the computer because the user let it. No system will protect someone with admin access to the machine from compromising the computer if that user chooses.
The article is pretty useless; they even complain that the MS Malware Removal Tool doesn't remove all malware... well duh, it was never designed to and it's not supposed to replace actualy anti-virus or anti-malware software. It's supposed to catch common and easily fixed malware.
But the discrimination affected everyone.
No it didn't. As I white, I could sit anywhere I wanted on a bus. How did that negatively affect white people?
But I don't and I didn't. Time for me to stop reading your post right there, troll.
That's rich, considering what you've posted thus far. Any reasonable person can see that you hate gays, for whatever reason. I guess when called out and backed into a corner, the bigot troll has to run and hide, hoping not to be seen in other threads.
Well, if it becomes the Next Big Thing, it will continue the perception to many that you shouldn't switch to Linux, because eventually another new distro flavor of the month will come along and what you have now work work quite right.