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.
>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.
Isn't most of the diagnostic information just stuff that's part of TCP/IP anyway?
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.
Sure, which is why it's useful. If the response doesn't get back it's not a reliable route. 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.
> 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.
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.
Most people define loss as the difference in assumed outcomes between scenario #1 and the illegal scenario #2 - a business has never been entitled to the full value of a person's enjoyment of a product. That's why most people scoff at the amounts cited by the record labels.
"a business has never been entitled to the full value of a person's enjoyment of a product"
..and a user has never been entitled to the full enjoyment of a business's product. But it doesn't seem to stop articles like this from being written or large amounts of users to just steal it anyway.
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.
This is true that Rosetta is a JIT, but my point was more that the Mach-O binary format allows for multiple architecture binaries, therefore somewhat obviating the need for a jit.
The only use Rosetta served was running cross architecture binaries.
Mono also doesn't run the full .NET stack, e.g. think the Netflix drm components, so I can't quite consider it cross platform. Cross platform windows wise sure, but that isn't saying much.
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.