FxChiP | 1 year ago | on: Traceroute Isn't Real
FxChiP's comments
FxChiP | 1 year ago | on: Traceroute Isn't Real
FxChiP | 1 year ago | on: Traceroute Isn't Real
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.
FxChiP | 13 years ago
FxChiP | 14 years ago
FxChiP | 14 years ago
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.
FxChiP | 14 years ago | on: I Think Your App Should Be Free
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.
FxChiP | 14 years ago | on: I Think Your App Should Be Free
FxChiP | 14 years ago
EDIT: By "tweaks" I mean "under the hood", as far as I can tell.
FxChiP | 14 years ago | on: Ultrabook: Intel's $300 million plan to beat Apple at its own game
Totally off-topic, but have you happened to start a print job on your machine and look at that light on Windows? That's my closest guess.
FxChiP | 14 years ago | on: Ultrabook: Intel's $300 million plan to beat Apple at its own game
FxChiP | 14 years ago
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.
FxChiP | 14 years ago | on: When patents attack Android
FxChiP | 14 years ago | on: When patents attack Android
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 :))
FxChiP | 14 years ago | on: When patents attack Android
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.
Oh -- as for Apple being the most innovative company... http://www.gsmarena.com/showpic.php3?sImg=newsimg/11/06/ios-...
FxChiP | 14 years ago
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...
FxChiP | 14 years ago | on: Google discontinues support for IE7 in Google Apps
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.
FxChiP | 15 years ago
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?
(EDIT: fixed problematic grammar)
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.