Ah, but that is not the proven fact you pretend it is. There is no proof at all that Google tweaks its results to put its own services at the top of the list. You have assumed guilt that has never been established in order to "prove" that Google is guilty.
Even companies are assumed innocent until proven guilty. That's called "justice" and if you don't like it, tough.
Obviously, you don't own an Android phone and have never owned an Android phone. Your criticisms are bogus. You don't have to have a gmail account to "login to" an Andoid phone. That's just a flat out lie. Unless you set up security, you just turn the phone on.
You actually want us to believe you were looking for iPhone apps on an Android phone? Yeah, sure you were.
If you are going to criticize Android, at least try it first.
The most common reason people stick with Microsoft is because they are familiar with the GUI. With this major switch by Microsoft, is there any reason not to switch to Mac or Linux? Some Linux distros look a whole lot like the GUI that many people know and love.
I don't understand the business plan of "Force users to adopt a GUI they don't like just because we want it." What business college teaches that course?
Of course, despite all that, a lot of people will probably stick with Microsoft because, well, "It's Microsoft".
No worries, though. Ultimately, life will fix the problem.
This is very, very true.
I used to run a small IT department and we would get these new graduates who "knew it all". My first job was to knock that out of them -- and it was extremely easy. The new grad's programs are inevitably over-coded, buggy things that didn't follow the specs, weren't documented and were extremely hard to use.
One trick my boss used when some new programmer bragged that his program was "finished": My boss didn't know programming and wasn't interested in test suites, he'd just walk over, mash the keyboard a few times, press return and watch the program fail spectacularly. Then he'd say, "Nope, not finished yet." and walk away.
You have absolutely no idea what you are talking about. There is not "the telephone company" and never has been. There are thousands of telephone companies. There is a basic agreement that every phone company forwards calls from other phone companies to the intended recipient -- otherwise the whole thing won't work.
So, in your "solution", which phone company are you going to punish? Hmmm?
Your local provider? Well then, how do they detect that this connection request is a robo call and that one is a legitimate connection request? Instantly. Without picking up the call and seeing who responds.
Gee, today, they can't detect that just from a connection request. Your "solution" isn't possible. Hence this exact request from FTC -- get it?
You do realize this isn't the first investigation Google has gone through? I seriously doubt this one will somehow damage their reputation unless they prove to be found guilty.
WTF!?
So, if someone has been hit before, it "does no harm" to keep hitting them? Are you serious?
"No harm"? You haven't ever been investigated, have you? You might be completely and totally innocent and still be ruined, financially and personally by an "investigation".
While Google won't actually be ruined by this, to claim that there would be "no harm" is extremely naive.
This is just like those people who say, "If you've done nothing wrong, you have nothing to fear from government spying."
I think you are confusing the O/S with the desktop software. The kernel isn't "designed for touchy crap", it's the desktop.
If you don't like touchy crap, use one of the bare-bones windowing solutions, like xfce.
The day you say to yourself, "I'm too old to change..." is the day you start to die. I can't remember how many times I've made major changes in my life. I'm always learning new stuff and I will as long as I'm alive. It is never too late to retrain, learn new stuff or even begin a whole new career.
I just said the important part is to have one environment that mimics production, not that every single environment mimics production. I meant that your software shouldn't break just because you developed it in dev then tested it later in preprod. The most that should change is a few configuration settings, and then your test is done for the test environment because your preprod is the same.
I'm not sure how you're able to deploy software without basic reading skills. Clearly I didn't suggest that you go straight from dev to prod and that they both can be completely different.
(Talk about "reading skills".) What you actually wrote:
The important part is to have one environment that mimics production. The rest can be completely different and if your software doesn't suck ass then it won't break.
Which one environment "mimics" production? Hmmm? DEV? TEST? Something else? You would actually waste your time developing in an environment that was "completely different" from production? Every hour programming in such an environment is an hour wasted. Or, were you saying that DEV was the one environment that "mimics" production and TEST is completely different? In that case, every single test done would be useless, meaningless and invalid.
Or were you actually thinking you'd develop and test in the "completely different" environments and then do some kind of a "test install" in the "mimic" environment? That's a total nightmare scenario.
Obviously, you have no real world experience in development, testing or deployment in a production environment. If you actually were in charge of a IT department and ran it like you propose, the company you worked for would be out of business in no time.
Too bad you haven't had any experience in the real world. How can someone trust tests done in a different environment than production? I especially like your testing success criteria: "if your software doesn't suck ass then it won't break". LOL!
That an application "doesn't break" is only the very first test in a long list of criteria. Many applications that "don't break" will still corrupt data or cause other existing applications to fail.
Development done in a different environment that production is a waste of time and testing in a different environment is useless. Good luck with your method.
I have often worked as a contractor for major corporations, and I have worked with contractors as a system administrator. I was not accusing you of anything but I was criticizing the environment you were forced to operate in. If the development environment gets so out of sync with production that installs succeed in development and fail in production, the solution is not to allow developers to change production but to correct the environment.
If production doesn't match development (and/or test) then the whole process is broken! Development is invalid and testing is invalid. Both development and test must duplicate production or absolutely nothing done in development or tested in test can be trusted.
As a developer, years ago, I actually modified a running production environment and I was very lucky that nothing went wrong. I understand that it happens and, in broken environments, sometimes it must be done, but that doesn't make it safe or right.
Sorry, no. I couldn't disagree more. I've worked in places like that, were developers were unable to get close to the production servers, things wouldn't work in production (but worked fine in dev) and we were unable to do anything except send builds with more and more debug info, working late nights to get things done, with a client more and more pissed each day.
Then it turns out that contrary to what they said, dev and prod wasn't identical, in a number of important things such as library versions.
If the install team is unable to install it by fuck's sake *get a developer see the installation process by himself* so he can come back just once with all the data he needs.
Then your process is screwed up. The solution isn't to open production to developers but to get your process fixed. Part of the process must be ensuring that the production environment is regularly and consistently copied over to development to ensure the problem you describe can't happen. That's the solution.
I have no problem with giving developers read-access so they can look at the production environment to "gather data" but developers must not be able to ever install or change anything in production. That's just good sense.
Top of the "billeted" list for us: A device that is open and is modifiable by the owner in any way the owner wants. In other words, the owner actually OWNS the device and is in complete control of the device. That means Android.
I'm sure you still don't get it and probably aren't the type of person who ever will. That's why you think it's only about the "specs".
You will not understand why I will not tolerate waiting for the phone company to decide when, if ever, they update the O/S. You will not understand why I will not tolerate the phone company or phone manufacturer reaching into MY device and adding or removing programs without my OK. You will not understand why I will not tolerate the phone company or manufacturer telling me I cannot have some perfectly safe program or feature "just because".
Your ignorance is understandable and excusable but don't pretend you "know why" we make our decisions.
Sorry, I wasn't specific enough. It is my understanding that the UI elements that Apple has accused Samsung of violating Apple's patents on were added by Samsung and don't exist in the vanilla Android release.
Geez, never mind. It isn't important.
It was my understanding that the UI elements had been added by Samsung and are not in the vanilla Android. While Apple may, certainly, be gunning for Google, this lawsuit doesn't appear to have anything to do with Google's products.
Umm... That's already the way things are. If you join a union or run a bank or connect up with any group that throws money at politicians, you will get your "bailout". That's the way it works.
Slashdot Mirror
Ah, but that is not the proven fact you pretend it is. There is no proof at all that Google tweaks its results to put its own services at the top of the list. You have assumed guilt that has never been established in order to "prove" that Google is guilty.
Even companies are assumed innocent until proven guilty. That's called "justice" and if you don't like it, tough.
Obviously, you don't own an Android phone and have never owned an Android phone. Your criticisms are bogus. You don't have to have a gmail account to "login to" an Andoid phone. That's just a flat out lie. Unless you set up security, you just turn the phone on.
You actually want us to believe you were looking for iPhone apps on an Android phone? Yeah, sure you were.
If you are going to criticize Android, at least try it first.
The most common reason people stick with Microsoft is because they are familiar with the GUI. With this major switch by Microsoft, is there any reason not to switch to Mac or Linux? Some Linux distros look a whole lot like the GUI that many people know and love.
I don't understand the business plan of "Force users to adopt a GUI they don't like just because we want it." What business college teaches that course?
Of course, despite all that, a lot of people will probably stick with Microsoft because, well, "It's Microsoft".
No worries, though. Ultimately, life will fix the problem.
This is very, very true.
I used to run a small IT department and we would get these new graduates who "knew it all". My first job was to knock that out of them -- and it was extremely easy. The new grad's programs are inevitably over-coded, buggy things that didn't follow the specs, weren't documented and were extremely hard to use.
One trick my boss used when some new programmer bragged that his program was "finished": My boss didn't know programming and wasn't interested in test suites, he'd just walk over, mash the keyboard a few times, press return and watch the program fail spectacularly. Then he'd say, "Nope, not finished yet." and walk away.
You have absolutely no idea what you are talking about. There is not "the telephone company" and never has been. There are thousands of telephone companies. There is a basic agreement that every phone company forwards calls from other phone companies to the intended recipient -- otherwise the whole thing won't work.
So, in your "solution", which phone company are you going to punish? Hmmm?
Your local provider? Well then, how do they detect that this connection request is a robo call and that one is a legitimate connection request? Instantly. Without picking up the call and seeing who responds.
Gee, today, they can't detect that just from a connection request. Your "solution" isn't possible. Hence this exact request from FTC -- get it?
You do realize this isn't the first investigation Google has gone through? I seriously doubt this one will somehow damage their reputation unless they prove to be found guilty.
WTF!?
So, if someone has been hit before, it "does no harm" to keep hitting them? Are you serious?
If Google is innocent, then no harm no foul.
"No harm"? You haven't ever been investigated, have you? You might be completely and totally innocent and still be ruined, financially and personally by an "investigation".
While Google won't actually be ruined by this, to claim that there would be "no harm" is extremely naive.
This is just like those people who say, "If you've done nothing wrong, you have nothing to fear from government spying."
I don't think you are trying hard enough to get insulted.
There may be millions, even billions, of phrases, images and articles on the Internet that you could use to get very, very insulted.
You had to search and then download that video from YouTube. Why don't you just keep searching and downloading stuff that offends you.
You aren't even trying here. With some ingenuity, you could find stuff to make you outraged for the rest of eternity. Let's get cracking!!
I think you are confusing the O/S with the desktop software. The kernel isn't "designed for touchy crap", it's the desktop. If you don't like touchy crap, use one of the bare-bones windowing solutions, like xfce.
The day you say to yourself, "I'm too old to change ..." is the day you start to die. I can't remember how many times I've made major changes in my life. I'm always learning new stuff and I will as long as I'm alive. It is never too late to retrain, learn new stuff or even begin a whole new career.
I just said the important part is to have one environment that mimics production, not that every single environment mimics production. I meant that your software shouldn't break just because you developed it in dev then tested it later in preprod. The most that should change is a few configuration settings, and then your test is done for the test environment because your preprod is the same.
I'm not sure how you're able to deploy software without basic reading skills. Clearly I didn't suggest that you go straight from dev to prod and that they both can be completely different.
(Talk about "reading skills".) What you actually wrote:
The important part is to have one environment that mimics production. The rest can be completely different and if your software doesn't suck ass then it won't break.
Which one environment "mimics" production? Hmmm? DEV? TEST? Something else? You would actually waste your time developing in an environment that was "completely different" from production? Every hour programming in such an environment is an hour wasted. Or, were you saying that DEV was the one environment that "mimics" production and TEST is completely different? In that case, every single test done would be useless, meaningless and invalid.
Or were you actually thinking you'd develop and test in the "completely different" environments and then do some kind of a "test install" in the "mimic" environment? That's a total nightmare scenario.
Obviously, you have no real world experience in development, testing or deployment in a production environment. If you actually were in charge of a IT department and ran it like you propose, the company you worked for would be out of business in no time.
Too bad you haven't had any experience in the real world. How can someone trust tests done in a different environment than production? I especially like your testing success criteria: "if your software doesn't suck ass then it won't break". LOL!
That an application "doesn't break" is only the very first test in a long list of criteria. Many applications that "don't break" will still corrupt data or cause other existing applications to fail.
Development done in a different environment that production is a waste of time and testing in a different environment is useless. Good luck with your method.
I have often worked as a contractor for major corporations, and I have worked with contractors as a system administrator. I was not accusing you of anything but I was criticizing the environment you were forced to operate in. If the development environment gets so out of sync with production that installs succeed in development and fail in production, the solution is not to allow developers to change production but to correct the environment.
If production doesn't match development (and/or test) then the whole process is broken! Development is invalid and testing is invalid. Both development and test must duplicate production or absolutely nothing done in development or tested in test can be trusted.
As a developer, years ago, I actually modified a running production environment and I was very lucky that nothing went wrong. I understand that it happens and, in broken environments, sometimes it must be done, but that doesn't make it safe or right.
Sorry, no. I couldn't disagree more. I've worked in places like that, were developers were unable to get close to the production servers, things wouldn't work in production (but worked fine in dev) and we were unable to do anything except send builds with more and more debug info, working late nights to get things done, with a client more and more pissed each day.
Then it turns out that contrary to what they said, dev and prod wasn't identical, in a number of important things such as library versions.
If the install team is unable to install it by fuck's sake *get a developer see the installation process by himself* so he can come back just once with all the data he needs.
Then your process is screwed up. The solution isn't to open production to developers but to get your process fixed. Part of the process must be ensuring that the production environment is regularly and consistently copied over to development to ensure the problem you describe can't happen. That's the solution.
I have no problem with giving developers read-access so they can look at the production environment to "gather data" but developers must not be able to ever install or change anything in production. That's just good sense.
Top of the "billeted" list for us: A device that is open and is modifiable by the owner in any way the owner wants. In other words, the owner actually OWNS the device and is in complete control of the device. That means Android.
I'm sure you still don't get it and probably aren't the type of person who ever will. That's why you think it's only about the "specs".
You will not understand why I will not tolerate waiting for the phone company to decide when, if ever, they update the O/S. You will not understand why I will not tolerate the phone company or phone manufacturer reaching into MY device and adding or removing programs without my OK. You will not understand why I will not tolerate the phone company or manufacturer telling me I cannot have some perfectly safe program or feature "just because".
Your ignorance is understandable and excusable but don't pretend you "know why" we make our decisions.
Actually, you weren't listening. We buy Android phones because we want to buy Android phones. Got it?
I so like this interpretation!
Sorry, I wasn't specific enough. It is my understanding that the UI elements that Apple has accused Samsung of violating Apple's patents on were added by Samsung and don't exist in the vanilla Android release.
Geez, never mind. It isn't important.
It was my understanding that the UI elements had been added by Samsung and are not in the vanilla Android. While Apple may, certainly, be gunning for Google, this lawsuit doesn't appear to have anything to do with Google's products.
Nice, now what part of the lawsuit targeted Android again?
I'm sorry, what part of the lawsuit was about Android? I must have missed that.
The lawsuit had nothing to do with Android. Your statement would make sense if you'd said "every smartphone manufacturer".
First they should actually show that this is a significant problem that requires the heavy hammer of government intervention.
Umm... That's already the way things are. If you join a union or run a bank or connect up with any group that throws money at politicians, you will get your "bailout". That's the way it works.
For the rest of us, not so much.
Huh? Does not follow.
I do not accept any party affiliation. You, however, consider yourself a "Democrat" don't you? How do you like having others tell you what to think?