> If the response doesn't get back it's not a reliable route.
It's not a reliable route specifically for the response packet from the intermediary to the original host -- and that might be because it gets routed out the wrong interface. It could also be because the intermediary doesn't send anything at all (which would therefore mean nothing about the validity of the route either way).
> It seems like you're saying tracert is bad because of some sort of circular reasoning where you've decided it's bad so it's bad.
I didn't even say tracert was bad. I even said on simple, straightforward routes where everything cooperates and everything aligns properly, it's great. There are just lots of external factors to keep in mind that have nothing to do with the end user that might inadvertently affect its usefulness.
The diagnostic information is really two things: (1) whether you get the packet back to begin with and (2) where it comes from and the ICMP state, which, yeah, is stuff that's part of IP anyway. The point was that the response is also a packet, and subject to all the same potential issues as the packet it's responding to.
Not only is it contingent on your intermediaries actually responding to your packet with the diagnostic information you want, it assumes that the diagnostic response will also be able to get back to you. If, for instance, your links are failing over super frequently or you have something hilarious happen like the response packet ALSO having a too-low TTL, you may not get a response as you expect.
But wait, there's more! Precisely because of that stepping-increase of TTL, by necessity, it must send as many TTLs as necessary to reach the endpoint. That means one packet per TTL. Remember what I said about links flapping? There is no guarantee that any two packets will or even should go the same route, for any number of reasons, some potentially even legitimate. In some situations you may see different hops between hosts that aren't actually even physically connected!
And I love MTR, but it can handle some of these issues really... interestingly. I seem to semi-regularly see it in a state where it's showing a bunch of packet drops, but really I just have to refresh the display because some state or another got desynchronized.
That said, on simple paths that don't change a whole lot, it's great. A very clever way to expose information you might not otherwise ordinarily have that might even be key to resolving any given issue. You just have to remember just how surprisingly much of networking is made up.
Be sure to read the documentation though -- at the very least, keep in mind that they do not honor query strings, so any dynamic (I.e. behind a script) content you may want cached, you may have to do a little webserver rewrite magic for.
> Yeah, because the constant feuds within the Linux community, the failure to settle on a common desktop platform, the crowd of "I-want-to-write-yet-another-irc-client" devs, and the utter lack of appreciation for end-user needs all have nothing to do with it.
Everyone seems to like bitching about these sorts of things in the open source commmunity, yet no one seems to like doing anything about it.
"it's often a win if you stop fallaciously calculating every illegitimate copy as a loss of the sticker price."
This really depends on how you define loss.
In a standard legitimate sale of a product, there is a bidirectional exchange of value -- the customer submits currency whose total value is equivalent to the value requested for the product being purchased. Simultaneously, for submitting the currency of that value, the customer receives a product of that value. (We'll assume the price is totally fair and equivalent to value at this point, but even if it's not the price presumably still includes the true value of the product, if not more)
In an illegitimate transaction -- literal theft, in this case -- the criminal customer forcibly receives the product, exchanging nothing of value in return to the merchant or the producer of the product. In this case, there is no question of loss; the customer has received something with inherent value and given no value.
In the illegitimate transaction of piracy, the end result is the same as theft with the sole exception that the original product has not been "lost" in the traditional sense of the word -- however, the criminal customer has still received a product of value and exchanged nothing at all, much less the value of the product.
Now, regardless of which of these three transactions has taken place for your product, I am presuming that your product had a significant cost to develop -- unless, of course, all of your tools were free, you had no expenses at all and you regard your time as totally worthless, in which case all income from the product is profit. I submit to you, then, that if your costs in developing your product surpass the value you received for it, yet the value you received for it is, itself, surpassed by the value of the product "in the wild" -- e.g. you have sold $450 worth of software, yet there are $750 worth of copies of it total being enjoyed by people (purchased & pirated combined) (100% arbitrary numbers), and the cost to develop the product was around $1500 -- then you have certainly incurred a loss on the sole basis that you have not received enough value to cover your costs.
The standard rebuttal to this is the tried-and-true "but they would not have purchased my product anyway." Perhaps this is true -- however, I would consider this irrelevant. Under normal, legitimate economic circumstances, the purchase of a product is the only way to attain it; therefore, if they would not have purchased the product anyway, they wouldn't have the product. In this case, they have not purchased the product, but they do have it and enjoy its use, and you have received no value in return for it despite having put value into it.
However, assuming the value received for the product exceeds the costs of producing it, but the value of the product "in the wild" as mentioned above still exceeds the value received... perhaps "loss" is less correct in this instance, but you are still lacking the total value that under normal circumstances you should have received. What would you call that?
In any case, I am not sure how it is fallacious to call a product of value obtained illegitimately (one way or another) for free a loss to the product's producer.
Possibly, but it strikes me as unfortunate that someone would have to force ads on their users just to be compensated for their work developing an application.
My phone and Nook Color are both running CyanogenMod 7, which essentially amounts to stock Android 2.3.3/2.3.4 with tweaks. I do not think they could look more different from iOS. Where is this "resemblance" theory coming from?
EDIT: By "tweaks" I mean "under the hood", as far as I can tell.
The extra one that should be mentioned (but only for used Macs, I suppose) is "what was the latest Mac Apple dropped support for in OS X, and how much newer is the Mac you're looking at?" I hear with Lion they burned the Intel Core Duo (i.e. 32-bit) CPU Macs. Which are probably still pretty solid machines if you get some other OS running on them.
You keep saying "without using a vm/jit" like it's something Apple did, but in reality, Rosetta is a JIT and not every Mac OS X binary for PPC was a Universal one (which, incidentally, caused a few problems when Rosetta's translation wasn't up to par, either).
Also, .NET is "portable" not just across Windows releases, but through the work of Mono large portions of it also work on Linux, and on other architectures via Linux as well -- so presumably, anywhere Mono or Microsoft's official .NET are compiled, .NET will run so long as no weird x86- or binary-specific things (like P/Invoke) are done. There are other problems with Mono, however, but those are for another discussion.
(I forgot to mention also that manufacturers and carriers also seem to have a lot to do with the overall interface -- Samsung's stock Android for the Captivate, for example, does mirror iOS quite a bit, while HTC Sense probably couldn't be much more different if they tried!)
"Google extremely blatantly cloned the look and feel of the iPhone and have pursued a strategy of dumping Android in an attempt to reduce smartphones to a commodity."
There are actually quite a few differences between Android and iOS in terms of interface, and there always have been -- in fact, many features found in later versions of iOS were found first in earlier versions of Android, such as copy & paste, wallpapers, and the upcoming notification area. In addition, applications are presented differently (you have to slide up a panel, generally, or tap a button somewhere to get to them), wallpapers can be dynamic (Live Wallpapers), and Android is, in general, much more reliant on menu structures than iOS, which seems to take a more simple and transparent route to most functions.
Sure, there are similarities -- like the fact that it's a touch interface and applications are represented first as icons -- but I'm inclined to think they're less prevalent than seems to be thought, and the ones that are there are (more or less) common sense. (I could be wrong, of course :))
"The problem with this is that prior to the introduction of the iPhone, android was designed to look like and work on phones like the blackberry. It was a better feature phone OS. After the iPhone came out, Google changed courses and counterfeited the iPhone.
If google wanted to compete, they could have spent 7 years investing in fundamental innovations-- like Apple did with touch-- to create their own new UI. Maybe they could have done a voice driven phone. OR, if touch was inevitable, they could have done their own, innovative take on touch UIs.
They did not. They turned around and cloned the iPhone and then gave the OS away for free."
Fundamentally incorrect; the T-Mobile G1 running Android 1.0, 1.5 and 2.0 (with modification), did, in fact, come with its own user interface, utilizing widgets on the home pages, wallpapers before iOS was even capable of such a thing unjailbroken, and a different method by which the applications are accessed -- those particular elements are present to this day in Android software. Notably, it wasn't until 2.x that the G1 gained multitouch. Back then, Android's home screen metaphor more resembled the standard desktop of a computer than anything else -- of course, with the addition of widgets. On top of everything else, Android did notifications in a brand new way -- in fact, in a way that was so innovative, Apple ripped them off in iOS 5!
Also, in 2.x, Android gained the feature of dynamic image wallpaper -- i.e. "live wallpapers" -- where the wallpaper is quite dynamic. This is a feature Apple simply does not have yet.
Furthermore, there are different interface conventions in application design, different methods of application development -- in fact, an entirely different language with a platform-agnostic binary format, and, in general, different UI mechanisms for everything.
This is not even to mention copy & paste, which Android had before iOS proper did.
In short: they did not clone the iPhone nearly as much as you say they did. Manufacturers are the ones that did that later, with form factor.
"They were able to do this because the patent system requires Apple to publicly disclose their inventions. In exchange for this disclosure, Apple gets a monopoly on the use of their inventions. If you don't like this, that's fine, amend the constitution, and take it up with your congressman."
Actually, just because Apple publicly disclosed their patent doesn't mean Google read the patent and purposely implemented anything exactly the same way Apple described. In fact, I'm absolutely positive that multitouch doesn't work quite the same way simply because the API to access touch is completely different. The end (user-facing) result winds up the same, though -- but the end result is what's at issue here, isn't it? To that end, I'd say, sure, multi-touch is copied -- but, there aren't a whole lot of common-sense ways, on a screen like that, to enlarge something (beyond buttons and such).
"Google is now claiming that the government should step in and use force-- that is, decrees backed by men with guns and the threat of violence-- to allow google to steal other companies innovations and get away with it."
Blatant, incorrect hyperbole -- unless you can back up the "use force" part. No, the DoJ is stepping in because the major parties involved with the Nortel patent acquisition are also direct competitors with Google -- in fact, the parties are all the major mobile companies that aren't Google. These are companies that did not invent or patent the technologies themselves, but the patents are going to them and are potentially usable for the purpose of crushing Android with litigation rather than by the merit of the products themselves.
"Think about that. Google cannot compete fair and square, so they steal their competitors technology. When this is pointed out, they call for the use of violence to let them get away with it! Talk about Doing Evil!"
"They call for the use of violence" -- citation needed. Honestly, the fact that Google's competitors seem to be (may not be, but the patent acquisition seems to be far more than coincidence here) colluding to squash Google by means of patent litigation is more evidence that Google's competitors can't compete "fair and square", that is, by technical merit.
"People only say 'anti-competitive' when someone is competing successfully and they don't like it."
This sounds like something that would be strangely pro-Microsoft back when MS was abusing its monopoly... but a move to block new competition from entering a market, or a move to exclude (by disqualification) a very specific competitor seems pretty anti-competitive to me.
"Either way, Once again, Apple-- the only company in Silicon Valley with a track record of genuine innovation--"
Are you ignoring Facebook or something? I'm fairly certain Google's search engine indexer is genuinely innovative, too. Oh my.
"If its taken away from them, it will not be justice, and it will not be moral."
If it's not, it will not be moral to allow three out of the four mobile companies to arbitrarily kick the fourth out just because none of them can top it or stop it on technical merit alone.
Sometimes OSes are deemed obsolete for whatever reason, and browsers -- all of them! -- simply stop developing for those OSes. This means that you're at least shelling out the cost for a new OS, which can be (1) painful (if you're using Windows or Linux in some cases) or (2) impossible (e.g. if you're using Mac OS X and Apple has decided that your hardware is "end-of-lifed" -- e.g. PowerBook G4). If you're one of the unlucky ones to be in the latter category, you actually have to shell out enough money for at least some upgraded hardware (perhaps in addition to the OS), or possibly a brand new (or newer but still used) computer, which will likely be a lot more painful than just shelling out for the OS.
The key point is that Google Apps are tied to browser versions, and browser versions are tied to OS versions, and OS versions aren't exactly consistent in their support or end-user coverage. Users who figured their current setup works well enough for now, and who for many years haven't had any reason to upgrade will now be forced to if they want to make use of those Google Apps -- or, they can take the much less costly route and simply not use Google Apps, or deal with "simple HTML mode" or whatever.
The worst part about this that irritates me most, though, is that many of these systems simply don't have anything wrong with them except that someone, somewhere, arbitrarily decided they were "too old". So perfectly functional pieces of equipment now lack functionality because enough people have arbitrarily decided that they "don't have" that functionality anymore, even where it might actually be possible.
On the plus side, it does mean that no one has to support old browsers' quirky and always-varied interpretations of the same chunk of code...
And in general, it's not. But certain platforms (e.g. OS X on PowerPC) have been artificially restricted to the point where no new browsers are being made for them, so the latest version you can get to on them is probably outside of Google's scope of support -- and if it isn't now, it will be shortly. For instance, sure, a PowerBook G4 isn't necessarily powerful by today's standards, but surely it's powerful enough for Google Apps, yet today I don't believe it's supported in the current version of any browser because of its inherent OS X 10.4 or 10.5 cap. Sure, it's possible to switch to Linux, but I don't personally believe the user should have to.
In essence, upgrades are not as simple as you may think due to forced platform incompatibility/vendor lock-in. Forcing an upgrade like this can cost users a non-trivial sum of money on top of what you're already charging for the service!
So while I appreciate the moving into the future, I feel bad for the people whose wallets are going to feel the pain of such a move.
If an audit of his computer revealed unlicensed movies, songs, fonts and applications, I (and probably he) would fully expect him to be litigated against -- such discoveries and resulting lawsuits are quite commonplace nowadays, it seems like. That doesn't make it right for anyone, even a large corporation, to violate intellectual property law.
To put another way: if I were found to be pirating Mac OS X, Apple would be in the right to sue me for intellectual property violation. If I found them to be using my code outside of the license I provided it to them (and the rest of the world) with, I should be in the right to sue them for intellectual property violation. Is this not correct?
It's not a reliable route specifically for the response packet from the intermediary to the original host -- and that might be because it gets routed out the wrong interface. It could also be because the intermediary doesn't send anything at all (which would therefore mean nothing about the validity of the route either way).
> It seems like you're saying tracert is bad because of some sort of circular reasoning where you've decided it's bad so it's bad.
I didn't even say tracert was bad. I even said on simple, straightforward routes where everything cooperates and everything aligns properly, it's great. There are just lots of external factors to keep in mind that have nothing to do with the end user that might inadvertently affect its usefulness.