GIGABYTE ripped me off

Are you asking me to tell you what you are saying and what evidence you have to support that?
I'm referring to your evidence.

When people point the finger at Gigabyte, they use the identical EAN as the evidence.
Which is insufficient.

As I have consistently been saying, EANs are a standard way to track products. You can differentiate products in numerous different ways, but irrespective of however you do that, unless you want to manually track and manage products, you'll need to use an EAN/UPC/other barcode on the packaging or your own barcoding system. We've already seen that the Gigabyte products only have an EAN, which means that unless a distributor or retailer puts their own additional barcode onto these products, they cannot track the different revisions of the products separately. It is as simple as that.
You are making the assumption that it's the only code. You know what they say about assumptions?

Once again, by giving the different revisions the same EAN, Gigabyte is asking for them to be treated interchangeably.
Again that is your assumption. Gigabyte isn't even treating them the same on their website which is more than most manufacturers are doing so if there's any assumption to be made it's that they are trying to differentiate them. EANs are regularly not updated when one revision of a product replaces another.

I have never once said that this is malicious. I think that it is poor practice, and Gigabyte is definitely at fault if there are substantial changes between these revisions. This isn't to say that the retailer could not have also done things better.
It has been standard practice for decades. Without knowing the details of the supply chain we can't say anymore about who is really at fault. With that said it has always been enough with brick & mortar shops. There was no reason to think that it would become insufficient for online shops.

I am glad that discussion about it has opened up and I do think the supply chain needs to change but I don't think blame should be assigned until all involved parties have responded.
 
I'm referring to your evidence.

You're going to have to specify just what you are talking about.

Which is insufficient.

Which you claim is insufficient, but without a convincing argument so far.

You are making the assumption that it's the only code. You know what they say about assumptions?

That's an inductive inference, actually. We have pictures of the EAN and component details. Since all components that I have previously encountered have located the barcodes in the same area, I therefore concluded that if there were any other barcodes, then they would have appeared in those pictures.

Again that is your assumption. Gigabyte isn't even treating them the same on their website which is more than most manufacturers are doing so if there's any assumption to be made it's that they are trying to differentiate them. EANs are regularly not updated when one revision of a product replaces another.

This is an abductive inference. An EAN is an identifier. Its purpose is to provide a barcode that identifies products. As far as I can tell there are three likely explanations as to why Gigabyte would retain the same EAN with different revisions. First, they want systems that track by EAN to treat the products as identical. Second, they made a mistake in assigning two different revisions the same EAN. Third, they are screwing around or trolling or not using EANs seriously. Since the second two are implausible, we can consider the first the best explanation. You're welcome to provide your own explanation here, and then we can decide which is best. Note that 'standard practice' isn't an option here, because that just collapses into the first option. If it is standard practice to give different revisions the same EAN, then that implies it is standard practice to have EAN tracking systems treat different revisions as if they were the same product.

It has been standard practice for decades.

Then I'm sure it will be no trouble for you to find other products with significant revisions, like the product in question in this thread, that have retained the same EANs and present that evidence here.
 
You're going to have to specify just what you are talking about.



Which you claim is insufficient, but without a convincing argument so far.



That's an inductive inference, actually. We have pictures of the EAN and component details. Since all components that I have previously encountered have located the barcodes in the same area, I therefore concluded that if there were any other barcodes, then they would have appeared in those pictures.



This is an abductive inference. An EAN is an identifier. Its purpose is to provide a barcode that identifies products. As far as I can tell there are three likely explanations as to why Gigabyte would retain the same EAN with different revisions. First, they want systems that track by EAN to treat the products as identical. Second, they made a mistake in assigning two different revisions the same EAN. Third, they are screwing around or trolling or not using EANs seriously. Since the second two are implausible, we can consider the first the best explanation. You're welcome to provide your own explanation here, and then we can decide which is best. Note that 'standard practice' isn't an option here, because that just collapses into the first option. If it is standard practice to give different revisions the same EAN, then that implies it is standard practice to have EAN tracking systems treat different revisions as if they were the same product.



Then I'm sure it will be no trouble for you to find other products with significant revisions, like the product in question in this thread, that have retained the same EANs and present that evidence here.


For your own peace of mind just ignore the wannabe as he will argue in circles and eventually claim you started his own argument! It's like this in all threads he partake in. He knows all about everything and believes everyone else is wrong. Must be a religious thing for him

Best is to place him on ignore.
 
For your own peace of mind just ignore the wannabe as he will argue in circles and eventually claim you started his own argument! It's like this in all threads he partake in. He knows all about everything and believes everyone else is wrong. Must be a religious thing for him

Best is to place him on ignore.
Really man? Are you so frikkin petty that you're going to drag your **** crusade against religion into just about every thread and disrupt the forum? Your personal attacks will be reported from now on.
 
Well I wasn't going to respond to this again but since Seriously has dragged up the issue again...

You're going to have to specify just what you are talking about.
The barcodes, which is your only evidence for this far fetched claim of malice.

Which you claim is insufficient, but without a convincing argument so far.
I don't need a convincing argument as I'm not the one with the burden of proof. You claim it to be sufficient but without a convincing argument so far.

That's an inductive inference, actually. We have pictures of the EAN and component details. Since all components that I have previously encountered have located the barcodes in the same area, I therefore concluded that if there were any other barcodes, then they would have appeared in those pictures.
Yes it's an inductive inference. That's my point. And it's one that's obviously incorrect as we know both manufacturers and suppliers have other codes which are not the EANs.

This is an abductive inference. An EAN is an identifier. Its purpose is to provide a barcode that identifies products. As far as I can tell there are three likely explanations as to why Gigabyte would retain the same EAN with different revisions. First, they want systems that track by EAN to treat the products as identical. Second, they made a mistake in assigning two different revisions the same EAN. Third, they are screwing around or trolling or not using EANs seriously. Since the second two are implausible, we can consider the first the best explanation. You're welcome to provide your own explanation here, and then we can decide which is best. Note that 'standard practice' isn't an option here, because that just collapses into the first option. If it is standard practice to give different revisions the same EAN, then that implies it is standard practice to have EAN tracking systems treat different revisions as if they were the same product.
You can't decide what's an option and what isn't. The first and most likely option for me is that they are simply assigning the same EANs to different revisions which has been a standard practice for decades and it's never been a problem before. It's only your conclusion that the most likely option is out of malice.

Then I'm sure it will be no trouble for you to find other products with significant revisions, like the product in question in this thread, that have retained the same EANs and present that evidence here.
That's not the argument. The argument is that if significant revisions share the same EANs it can't be automatically attributed to malice as it's been standard practice for decades to make revisions without assigning a new EAN. Not assigning a new EAN to a significant revision is therefor more likely an oversight especially seeing as development and marketing devisions are separate.
 
Top
Sign up to the MyBroadband newsletter
X