There is a long history of identifiers being reused in world shipping.
One of the staples of contracts class in the first year at many law schools is Raffles v Wichelhaus, an English contract case from 1864.
There was a contract for someone to sell a bunch of bales of cotton from India to a buyer in England. The contract called for the cotton to be sent on a ship called the Peerless to Liverpool from Bombay.
Unknown to both the buyer and the seller there were actually two different ships called Peerless both sailing from Bombay to Liverpool, one arriving in October and one in December.
They seller was thinking of the December one when signing the contract, and the buyer was thinking of the October one.
The buyer needed the cotton in October and when it did not arrive on the Peerless in October the buyer considered the contract broken and refused to accept the cotton that came on the December Peerless.
I think you’re right. If we add in some business about a portly porter who departed promptly from the port to go to a party while we were peering off the pier waiting for poor Captain Pearce of the Peerless to put in an appearance, I can practically hear it in Ronnie Barker’s voice. He might be the only person who could actually get through the script without stumbling.
You’d think serious contracts would normally have provisions that would require mentioning expected dates, since late shipments would presumably be a common occurrence you’d want all parties to consider explicitly.
According to A.W. Brian Simpson, "Contracts for Cotton to Arrive: The Case of the Two Ships Peerless", Contracts Stories, p43,
> A contract for cotton "to arrive" was a contract for forward delivery, or, as it is sometimes called, a "time contract". One might expect that such a contract would normally specify a time for delivery. For it is the moment when the goods become available in the market that is of paramount importance to the purchaser, particularly if the purchaser wants the goods for use. But the world in which such contracts originated was one in which this was not really possible. Although one could discover, after an interval, when a sailing ship had left or, more approximately, proposed to leave its port of departure, it was very uncertain when, if ever, it would arrive at its destination. Even when it did arrive, there were uncertain delays in finding a berth to unload its cargo. Hence such contracts did not originally specify the time of arrival, much less delivery, even within some fixed period. All they did was to identify which shipment of cotton was being sold; presumably the rationale of this was that the buyer, so long as he knew which shipment was being sold, would be able to form his own estimate of the probable time of arrival. This would not, of course, be a point in time but a period. It is said that originally such contracts were made only when arrival was imminent, the ship typically having been reported off Point Lynas, which is on the north coast of Anglesey, some fifty miles from Liverpool. Presumably there was a signal station there. No doubt also cotton was sometimes sold as the ship lay in the river, waiting to berth. In such cases the date of delivery could be guessed with some precision, though a square-rigged vessel, if it did not employ a steam tug, could take a long and unpredictable time to cover even fifty miles.
The author also provides the broader context, which is that this was likely a form contract in the nascent commodity futures market. Additionally, this occurred during a period of particularly overheated speculation in cotton. In other words, just as is common today, financial speculators were pushing the legal and technological envelope of the instruments available to them. (Futures markets go back much further, but the mid-19th century is in many respects when modern futures markets began to take on their current shape. He cites another source pointing out that in "'in certain offices in Liverpool today the futures department is still called the Arrivals Department.'")
Reading this case, I'm surprised at the outcome. The seller fulfilled on the terms of the contract.
The contract also didn't specify the precise color or weight of the cotton, the exact destination, etc etc etc so the defendant could make similar claims to renege on the contract.
Granted, time is arguably special inasmuch as it allows the seller to construct a scenario for fulfillment, e.g. the seller could've delivered 100 years later on a new boat that happened to be named Peerless. That's clearly not the intent.
In that sense, a contract can be considered void if it doesn't reasonably specify time.
> In that sense, a contract can be considered void if it doesn't reasonably specify time.
The judgment states pretty clearly that a contract is void if the two parties, at the time they made the contract, did not agree on what it meant.
> the moment it appears that two ships called the “Peerless” were about to sail from Bombay there is a latent ambiguity, and parol evidence may be given for the purpose of shewing that the defendant meant one “Peerless,” and the plaintiff another. That being so, there was no consensus ad idem, and therefore no binding contract.
[The words are from the defendant's lawyer, but the court appears to have agreed immediately.]
So this isn't formally a "win" for the defendant - formally, there never was a contract, and the suit was dismissed for failure to state a claim.
My point is that NO CONTRACT perfectly spells out every detail => this argument can be used to null any contract => weak legal reasoning. A buyer could make up any sort of nonsense to escape a contract, like (to pick a random example) arguing that a certain social media site has x% fake accounts.
Far stronger reasoning (for example) is that a contract must spell out time, which is a special property of contracts because (for example) 1000000 years is virtually never an acceptable period for which to fulfill on your end of a contract.
This isn't really how contract law works. There may be minor details that are not specified in the contract but unless it can be proven in court that those details were actually within the contemplation of one of the parties and connected to his or her decision to enter into the contract, their absence would not be sufficient to nullify the contract.
A contract is an agreement, so it stands to reason that if the parties do not, in fact, agree, there is no contract. The piece of paper we call a contract is, in fact, only a (strong) evidential tool to help the court figure out what the parties agreed.
> Far stronger reasoning (for example) is that a contract must spell out time, which is a special property of contracts because (for example) 1000000 years is virtually never an acceptable period for which to fulfill on your end of a contract.
How is this "far stronger reasoning"? It isn't even reasoning at all, because there is no existing rule that a contract must spell out time, so it's simply an untruth. Unless you were suggesting that the court create a new rule out of nowhere that all contracts must spell out the time for performance or else become void. A court would obviously never do that in light of the huge disruption it would cause.
I felt bad for the seller for a while. Then I realized they probably just sold the cotton to someone else, and that fungibility and liquid markets make a lot of this stuff less risky on both sides.
But the price was probably settled well in advance, so the seller was left taking on market risk, which depending on the way things went, could have been anything between a bad loss or a nice windfall. Less likely the latter, I would expect, since they were forced to sell the cotton in Bombay or cover the cost of transport elsewhere.
>But the price was probably settled well in advance, so the seller was left taking on market risk,
No. That was the whole problem. It was for market price when the cargo arrived and the price of cotton jumped between October and December. So the buyer didn't want it any longer and basically claimed they thought it was going to be on the October boat.
I think that all the analysis I've found with a quick search isn't very helpful.
The seller had to sue to either obtain payment or void the contract or else spend energies and time pursuing payment by persuasion whilst the entire time granting the ostensible buyers a free call option on FOB Liverpool cotton. My cynical guess is that regardless of evidence of foreknowledge about the duplicate ship names, Lloyds Register [0] most certainly did exist and importantly was considerably more accessible from Liverpool than India. Seller's imperative wasn't recompense but prior to marketing the cargo and taking profit, obtaining title and clean hands. Why go to so much effort? Letters of credit access and costs issues that could have been affected by a impossible distance impedance to necessary restorative PR.
I wonder how this has played out in the doubtless many other contract law cases. If this was really a case of (apparent) confusion on both sides, really not much hard/foul to either, so just void the contract. I assume you might see a different result if there was significant hard that fell disproportionately on one party.
We encounter this all the time at work. New customer, so new integration. What's your unique shipment reference? This one? Ok fine. Go into production, and after a few months we get missing shipments. Support check, missing shipments have same reference as old shipments. "Oh, yeah we reuse the references after about 90 days... And, no, we don't have any globally unique references."
This is fun when so much of the flow is based on these references, think goods arrival scanning, and sometimes shipping does take a long time so 90 days or whatever is cutting it close.
This is what we've never understood. Trying to ask why is almost always futile, the people who're there now never knows.
I suspect it's often some legacy stuff, like a certain system only had 6 chars available for the reference, and so that's how they ended up working around it and nobody realized that limitation no longer exists.
Is it a fully computerised B2B system? I mean when I order some patch cables for a project, I do it via a web shop and pay with my corporate credit card. The vendor generates an order number but also asks me for customer purchase order reference. I just make something up that might have my initials and date and a serial like "MV-20220723-1". Others may not be so methodical.
This reminds me of a project I was remotely involved with: Airbus having to handle an aircraft order number above 5 digits as they were delivering their 10’000th aircraft to a customer.
This was a multi year project where we had to deliver software used
to map risk and impact across the whole company.
Yeah I mean I also get that aspect. We integrate with many systems, we have 18 different integrations with one of our larger customers, and we're just a small piece of the puzzle.
Would likely be super costly just to figure out which, if any, of the systems that would have to change.
Even the USPS reuses tracking numbers. I had a package show as "delivered" before it even shipped once, because it received a recycled tracking number.
I don't even reuse references inside a single running instance of software. Using u64 you can generate billions a second and still not run out for hundreds of years.
USPS tracking numbers are at least 22 digits long (depending on shipping method; some can be 27); I don’t think ease of data entry was a priority for them.
22 digits and they somehow still manage to reuse tracking numbers. 10^22 (or 10^20, if we assume some encoding overhead) valid numbers should be able to uniquely identify a lot of mail.
For the ones you mention that have 22 digits, the first 8 digits (if memory serves) identify the class of mail service and other metadata. So that leaves you with 10^14 at most, assuming there’s no encoding overhead / check digits.
> USPS tracking numbers are at least 22 digits long
Actually, that’s wrong. There are shorter ones.
Examples:
82 000 000 00 - Global Express Guaranteed
EC 000 000 000 US - Priority Mail Express International
CP 000 000 000 US - Priority Mail International
There’s also foreign shipped packages that will follow various standards that aren’t 22 digits, yet are still technically a valid USPS tracking number.
They might need a new type of identifier to guarantee uniqueness. And there might be cost associated with updating the system (workflows, databases, scanners, training, etc) to deal with new type of identifiers.
I'm thinking either production or the warehouse still uses manual stamping of lot (or shipment) numbers with those auto-increment stamps... The number is then captured by hand into a system somewhere.
The system worked fine when production was X times smaller, but no attention has been paid to it since it was first designed.
Some legacy identifiers come in fixed length fields, insufficient for contemporary usage. I know a company where some identifier should have been lengthened long ago, but that would impact a couple hundred systems (and by system I mean whole applications, front and back) - so they keep plodding on with what they have and yes, it is a drag on operations and it causes endless hacks.
I have worked for a company that reused order-tracking identifiers. The reason was mechanical: The more digits in the identifier the bigger the barcode on the shipping label. A non-issue with 2D barcodes but back then it was an issue.
In some cases it’s a flag that there’s a mainframe underneath that people are afraid to touch with the number of digits fixed to save memory. So many other legacy systems assume the field is fixed that you can’t add digits. Companies then look and say, “We can spend tens of millions of dollars to fix this, or we can spend the money on advertising and compensation, and just deal with the issues that come with reusing numbers”
Totally different context, but at my company, they started reusing some IDs that are supposed to be unique because they ran out of them and the old-as-fuck computer systems can't handle longer IDs.
Another fun one is our customers which are close to the border. Sure a truck's ID (plates or similar) certainly definitely unique, but if the other warehouse is close to the border as well they can make multiple trips across the border in a day... Good times when that truck ID alone is used to trigger business processes.
>"Oh, yeah we reuse the references after about 90 days... And, no, we don't have any globally unique references."
The minute a simple unique identifier is established for something, someone who is just important enough not to be told "no" screws it up.
A thing that I've seen is that people want things to be grouped together in reporting, so they insist on it having the same identifier as all other things in the same group.
Sooner or later, they ask for a report that distinguishes between them, though.
> Consequently, as there was no consensus ad idem ("meeting of the minds"), the two parties did not agree to the same thing and there was no binding contract ... therefore, the [buyer] did not have to pay.
This is legit one of the things I love most about HN, articles might be 80% about tech, but the content in the remaining 20% can be about pretty much anything, and it's always fascinating to get insight into other domains. Never considered that containers were numbered, let alone that a number clash is a significant incident, but thinking about it, yeah it makes sense.
I suspect it's tied up in the shift of quantity/scope of "user generated content". News articles and blog-posts etc. got somewhat pushed out by "look at this cute cat photo I allegedly took myself", etc.
as HN evidences, this stuff is all still there (possibly more than ever), it's just drowning in an ocean of content aimed at pleasing children, Google's algorithm, and the less intellectually-inclined
And much more than trade. It had effect on road infrastructure, various temporary constructs including school rooms for emergency situations and housing as well.
It sounds like the actual unique number is only 6 digits long and chosen by the manufacturer, so it could either be a mistake or identical randomly generated numbers. My math is a bit rusty - how you you solve the birthday problem for 1mil instead of 365?
Yep, and it's pretty close in this case: for a 50% chance, a sample of 1178 containers with 6-digit numbers (assuming a uniform distribution) would suffice.
It’s worth noting the full number isn’t just the six digits (plus checksum) but the full number including the letters that indicate owner and type, so a single owner wouldn’t give two of their containers the same number.
That said, how many containers is one company likely to own? 1,000,000 is a big number but it seems like some of the big logistics companies could flirt with that. Doors anyone know if they have multiple “owner codes” or an I just way overriding the scale here?
I suspect they’ll move to Container.v6 and that everyone will dislike because the values are harder to read to say… then the industry will take an additional decade or two to actually start to use it.
Being a bit more kind, ipv6 only really started to get moving in the wild around ~2010 so we are at the start of the second decade. It has climbed steadily since this point and will be the majority globally within a couple of years. It is already the majority of traffic in the USA, Germany, France and India.
People will have to upgrade by the deadline. This is not unheard of (2004):
> Recently the Uniform Code Council (the organization that governs UPC bar codes) announced that starting in January 2005, they will require that all retailers and trading partners in the United States and Canada that presently scan 12-digit UPC bar code symbols be capable of scanning 8 digit EAN-8 and 13 digit EAN-13 bar code symbols as well. Furthermore, the UCC strongly recommends enhancing systems to accept bar code data of up to 14 digits in preparation for a new numbering system called GTIN (Global Trade Identification Numbers) that will eventually be used to identify products world wide.
Maersk has a capacity to ship 4 million containers at once. I suspect you’d generally have 3-4x that many because they spend a lot of time waiting around and also just pile up in Los Angeles because no one needs to ship (as much) stuff back to China.
I used to work for a company that sold labels for various third party printer manufacturers, and let me tell you, some of them were VERY lazy when it came to assigning MAC addresses.
MACs are supposed to be globally unique, but they only really need to be broadcast domain unique, so you can get away with using the same MAC for a lot of devices as long as most people don't use two on one LAN.
I worked for a company that made a networking product and we managed to build 1,000 units with the same MAC address (we had a big block of assigned addresses) because of a miscommunication with the vendor who provided the preprogrammed microcontrollers..
Luckily the MAC was in a rewritable location so it was possible, if a royal pain in the ass, to reprogram them all.
20-odd years ago, the college I attended (and worked for) was outfitting one of the computer labs with new network cards; migrating from Token Ring to Ethernet as I recall. To do this, 3COM cards had been bought by the boxful.
We replaced all of the cards, and booted the lab. 1 machine got an IP and then it all went to hell. Every single machine showed up with the same MAC. Think we had to rip and replace to fix it.
I'm having trouble finding a reference just now, but the MAC address for a modem-based link on Windows had "DESK" until it started causing real trouble. And one of those problems was that GUIDs were obtained by using "the MAC address" of the PC as an input to a DEC-Intel-Xerox-Microsoft algorithm. Around the time of this coming to a head, it came up that some manufacturers were out of MAC addresses for whatever reason, and also that some manufacturers were assuming that two random NICs on an Ethernet would not both be one of $MANUFACTURER's cards, so care was not necessary.
Worked for a small ISP in early 2000s. Not every new customer had an ethernet card in their PC and we had problems like installation crews calling the office that there is no port to stick the cable in.
The company obtained 300 cheap Intel PRO/100 Fast Ethernet NICs from China. The idea was that the crews would have a bunch of those cards to be able to install them in customers' computers.
Everything was dandy until second installation in the same building. For a little more backstory - it was a kind of shitshow infra with dumb switches and all customers in a building being in the same LAN.
So... the second installation in the same building rendered the former newest customer's link inoperable. Or wouldn't work, then suddenly there was connectivity, then there was no ping to the gateway but some other devices were pingable etc etc. The crew replaced the card with another one (from the same shipping), re-crimped RJ45s on both ends, changed switch port and nothing - same shit with random internet connectivity losses. Weird situation with seemingly no reason for what was happening.
It later turned out that the reason was that all 300 NICs had the same MAC address. All of them.
The container in question is SLHU4500470. The first four characters are the owner, the next 6 digits are the unique (per owner) number, and the last digit is a check digit.
Somehow I always assumed there'd be more than 6 digit IDs for these things. I'd guess collisions have happened, but never been caught in the same port before.
There's only about six million active containers in the world. If one owner has more than a sixth of them, an easy fix would be to issue them a second owner code, basically extending the six-digit field by a bit.
Though that's about 1 per 1000 people, and if you imagine how much stuff you'd end up with using all that a container could carry when constantly in use, I guess about a thousandth of that isn't too weird an amount.
6 million seems like a underestimate. There are meant to be 54k container ships in the world. That would mean an average of 110 containers per ship, and ignores all of the ones in use on land. Some of those ships can carry 24k containers _each_.
There are not at all a vast number of 8,000 TEU+ ships however. Small enough that any one ship owning company might have a few dozen at most. Evergreen says it has something like 150 ships.
Well, we'd probably just switch over to UUIDs since those things are practically infinite and we've now got a lot of well established infrastructure in place for handling them.
Nope, that many characters would be impractical in daily use. There’s a lot of copying, pasting, reading, and reciting of numbers via email/web/phone/TMS/WMS/etc.
I always wondered if this was designed to integrate into the existing railway numbering system. In the US, at least, owner identifiers are pretty consistently 4 characters or less, and individual unit numbers are 6 digits or less (i. e. BNSF 123456).
> “I have never seen two containers carrying the same number in my 27 years of career in the shipping sector,” pointed out Mohammed Abdullah Jahir, chief operating officer of Saif Maritime Ltd, adding that such an incident cannot be detected unless the boxes arrive at the same port at the same time.
If the port authority conducting the inspection are not diligent, it's easy to miss this.
I worked at a small "automall" of several dealerships. Our system operated inventory numbers based on the last 6 digits of the vin#.
Sounds like with 1 million options, you'd be fine.
It didn't take long for duplicates to start coming up when you have hundreds of cars in stock, and sell hundreds a month.
Let alone the problem with a car being sold new, and then being traded back in. That was fine, because we had a different leading digit for new vs used. But you'd be surprised how often a used car gets sold, and then traded in again at the same place. Now what number does it get? The same one. Fine, atleast they're not both in stock at the same time. Great. Sell it again. Then when a customer calls six months later, try and lookup the deal your most common way... Oh ya.. now I've got 4 possible deals for this car.
I wonder how common actually duplicated serial numbers are in various things. In some cases they do matter, but in many others not really. Think of the non-smart devices.
And it can often be simple human error. Some fat fingers the wrong range in morning, forgets to list the used codes, reads the wrong line, some glitch preventing machine from saving the last used code...
Just remember how much stuff is made by cheapest possible bidders, who might not be so much interested to deliver best work always.
Somewhere I worked used the wrong serial numbers of postal delivery. We had an overflow which no one noticed for about a year and we ended up using the same range as another customer of the postal company. There were thousands of parcels with duplicated serials, everything arrived fine and as far as I know there's been no real admin issues either. So in this case it didn't matter.
In this case, it appears to be a mistake. That a number was accidentally reused.
But a concern could also be fraud, theft, smuggling, etc. A “bad” container that was supposed to fly under radar mocked up to look legit if anyone checked.
This seems indicative of a security concern. When this happens it could indicate someone is trying to get a container full of e.g. explosives or chemical weapons to be shipped to a target city without a paper trail. Imagine if the malicious container had e-ink screens on the outside that allowed the numbers to be changed on the fly to route the container through multiple untraceable steps. :(
While TOCTOU is used to describe the problem encountered by software in general, an almost identical problem in lock-free data-structures is called the ABA problem.
Many years ago I encountered cheap knock-off network cards¹ that had default MACs in the range of a big known name brand, and as far as I know it wasn't some cross-branding/affiliate/other deal. So yes, there has been and no doubt still is.
[1] in fact, back in my student days most NICs I had were cheap knock-off versions, the "real" things were not the inexpensive items they are today. This predates it being common to have one built into your motherboard, even more expensive ones, by some time.
Several years ago I worked for a company that made a usb+network and usb-only skew of their product. The usb-only boards were the same as the usb+network boards with a few parts not populated.
We started getting tech support complaints when we sold the product into China. Turns out, an enterprising vendor bought a single usb+network printer, desoldered the EEPROM (containing the ethernet mac address). Then that vendor bought usb-only (cheaper) products, added the additional parts and bulk copied the single eeprom image (with the mac address) onto the new products, selling them as the more expensive usb+network sku. Result: a dozen+ of our product running on the LAN with the same mac address.
Sorry to side-track this, but does anyone know if there is a reason why we make homophone spelling errors? Do we sound words out as we write them? Neurologically, what is happening? It doesn't sound automatically the case that the pathways for concept -> word -> write actually flow through a concept -> word -> sound -> write path. It's not a confusion of the word since this user clearly knows SKU is not SKEW.
And /u/linuxlizard, if you don't mind saying, were you using speech-to-text to write that comment?
A decent proportion of the population frequently run internal monologues in the voiced manner - when I'm typing this out I can hear (not actually hear but mentally hear) someone speaking the words as I type. I assume the frequency of homophone typos are due primarily to this - since both skew and SKU are identical in my inner monologue and I'm trusting my fingers to choose the right combination.
I think homophone spelling errors are a different issue though - english education in the US is really quite poor so a lot of grammatical rules[1] (they're/their/there) and spelling aren't really well impressed on society at large - people will hear a term in conversation and start using it in their own speech, when they arrive at typing it out they'll make their best guess at spelling and it'll probably end up a roll of the dice which homophone their spell-check ends up shoveling them towards.
1. /me types while admitting they constantly type in spoken english - preferring the spoken sentence construction rules. Something something glass houses and stones.
> english education in the US is really quite poor so a lot of grammatical rules[1] (they're/their/there) and spelling aren't really well impressed on society at large
This is false. It was impressed into us many times throughout grade, middle, and high school. People just don’t care enough to get the right spelling because they were using the words natively long before they learned to spell them.
Backing this up- I see that complaint all the time about US education, but I know me and all my peers had this impressed on us throughout our (public) schooling. People just don't care because to them, the word is right but the spelling part is a formality that can be ignored.
Many years ago I worked for a major cellphone service provider in Europe - cellphones with duplicate IMEI numbers were an issue (the IMEI number was meant to be unique per cellular device much like a MAC address). This occasionally prevented an IMEI block on a stolen phone.
IIRC that's what some manufacturers did. However, rather than squatting in someone's existing range, they ended up squatting in unused ranges that were unlikely to be assigned anytime soon (back in those days the assignments were sequential). IEEE ended up cracking down on this by randomizing OUI assignments.
SHA-1 is a hash function. What did it in is that there was found a way to make different strings hash to the same value. This is just someone accidentally re-using serial numbers, it's not a weakness in some algorithm.
>So they running this port with pencil and paper? No database? No sanity checks?
Or they simply don't run those queries until they need to. i.e. "we don't give a F unless there's a hiccup"
The point isn't to track containers. The point is to get goods to where they need to be and when. Unless two of the same container shows up thereby causing a WTF moment there is no problem because there is no ambiguity in the container handling process and therefore they don't care.
How do you know this container isn't the same one you saw before? You need to have them at the same place at the same time to know they're the same container.
Suppose you were the guy who goes around numbering containers to begin with.
What are you going to use, a laptop or something?
If it ran out of power without completing its process, upon reboot it might very well assign the same number to the next container.
Even without a computer, you could have the day shift actually paint the number on the first container, but fail to finish the paperwork or it could get lost.
Then the night shift comes along and uses the same number on the next container.
I don’t see how a database (which they’re probably running anyway) would help, unless it’s connected to all other ports in the world an cross-examined for duplicates.
Which sounds like a lot of work and I’m not sure port operators want to share that, although it would be really cool.
It has been proposed in all serious several times - and then immediately the person proposing it was tarred and feathered, then disappeared by the relevant jurisdictions security services (only half kidding). I'd give you their names, but for some reason men wearing sunglasses and sitting in a van appear outside my house every time I consider it.
While they might consider THAT true, I suspect it has more to do with being able to track which companies and countries are doing what business with whom everywhere - especially if that includes countries they aren't supposed to be.
Tracking containers port to port everywhere would be a MOUNTAIN of useful intel.
Containers are already tracked. There's literally nothing stopping you from saying that container X is going to Italy when, in fact, it's going to Iran. Blockchain isn't magic.
Yes indeed, trusting something I can see and compute myself instead of trusting someone's promises. There's no way blockchain will ever be worse than just having to go along with it because there's no way to verify.
What exactly can you see and compute? The end result in the blockchain is the output of <something>, where <something> is any number of centralized actors putting data from opaque sources based on extremely complex contracts.
Run Postgres yourself. If Postgres developers are going to compromise their own software, it isn’t going to be to mislabel your shipping containers.
Most of the info in databases is boring and nobody cares about maliciously changing it it.
If someone were really interested in changing the number on your shipping container, blockchain can’t prevent someone with a $1 can of spray paint from changing it.
Sure, but the point here is to not lose the records too, which someone could trivially change if they own the Postgres DB. When I have a shared record of a container and somebody repaints its SN, at least I know I lost it, and I can also easily claim that I did not forge the records too because they signed the record with their wallet.
I worked in Bangladesh for 3 years, and it is such a land of contrasts.
The main electricity supply company at the time was running manual billings from a big room filled with manual general ledgers, one “T” account per household.
It is a humbling, impoverished country with its main riches being its resilient, kind, resourceful people.
Down the road/bay from Chittagong are the shipwrecking yards - a big time investment but worth watching is this…
https://youtu.be/5jdEG_ACXLw
<edit> the film I am looking for is Iron Eaters, a very human view of the horrific shipyards. The above film is from India, but still worth looking at.
I understand that ports don’t share container info with each other and manufacturers don’t have a crystal ball to see all container IDs of a given customer but given that first 3 chars identify a shipping company, I have hard time understanding how the shipping company failed to catch this. How did they manage to create two waybills for two containers with the same serial?
Ok but still: as a user, how do you even know that there are two containers with the same id? In other words, a human needs to have way of telling them apart.
Even if two entries showed up with the same id, I’d assume as a user it’s a glitch and would not put two different shipments into what I would assume is a duplicate entry for the same container.
I'd assume the containers were labeled at different ports and by chance got sent to the same port. So the persons looking at the containers only had one to worry about. And with both going to the same destination one person probably shrugged when they saw the origin port was somewhere else.
I don't know anything about shipping containers but I'd assume that the container owning company had the two doppel-containers enter service at different times and/or locations and their asset database either isn't centralized or isn't de-duped.
I’ve seen this type of thing happen a few times. Usually a combination of a human error at the factory plus flaky backend systems that like to do upserts.
The minute I started reading I was waiting for the phrase "made in China" to appear. It's in the 7th paragraph: " M Salam noted that the mistake occurred when containers were made for Sea Lloyd in China."
So a bit of a paint on container is used for routing? How feasible it is for criminals to repaint number on a container enroute to divert it and therefore steal its content?
Sounds like it, but I’m still interested in finding out how big a deal it is. A quick search shows that there have been cars found with duplicate VINs and making a container with the same serial number seems like pretty pedestrian crime in comparison. That is not to say that this is a crime, could just be plain old manufacturing mistakes and it’s also obvious that not all container management systems check for it (even if it did, unless both end up in the same registry it won’t matter anyway).
I have a custom license plate on my car in my state. A friend of mine told me they saw the same custom license plate on the same vehicle make/model in another state. The only bummer was that that car's color was red, whereas mine is yellow. So two cars with same plate is totally doable if issuing authorities are different. Two cars with same plate from same issuing authority, that's the problem
I imagine it would be a bigger deal if they had the same seal. _That_ would suggest someone was trying to steal cargo, or commit some kind of customs fraud.
Imagine if software engineering ID allocation failures made frontpage news in the trade press.
"An object reference was discovered to be null today in a web browser window in Frankfurt. Officials said the problem was discovered when some JavaScript application code attempted to read a property from the object reference."
I just had the very same thought reading the article!
"An admin at a local it shop discovered two 3com nics with the same Mac address while setting up a rack of four new servers. The admin got suspicious when reliable network communication was not possible with any of the two servers and after further investigation found the duplicate addresses."
I'm not sure if your quote is from personal experience but... and this is totally cliche from the era... I was setting up a Beowulf Cluster made up of salvage 486s in the early 2000s because why not? We were running into some really bizarre issues, and eventually we got down to the just pinging the machines from each other and started discovering that when we went to ping one of them, we would get two replies!
Sure enough, two generic NE2K NICs had duplicated MAC addresses!
Naturally, it started as a joke. My buddy had a pile of machines that the school board had decided to throw away. Being avid /. fans, I of course said “can you imagine a Beowulf cluster of those?”
So then it’s 2am and his basement closet is really warm…
I've had this problem in modern times where, when setting up Windows PCs (via WinPE at our enterprise) some NICs would very occasionally not work right with the provided driver and end up with some default MAC.
Doesn't work out so well when you have a room full of these PCs all getting imaged at thhe same time and suddenly half a dozen on the same switch have the same MAC. :\
(I believe it came down to a BIOS problem and a new version sorted it out.)
In the late 90s I worked for a company that was afraid of the Internet. They had one computer in a common area that had access to the Internet but not the company's internal network for the ~50 engineers to use.
The internal network was coax Ethernet. I was working on a networking project at the time and ran a packet sniffer on the internal network and saw that some MAC addresses could access the outside world.
I'm lazy and I didn't like having to go halfway across the building, sit at a slow ass computer to download a datasheet, copy it to a floppy, then walk halfway across the building back to my cube, and finally copy it to my computer. Ain't nobody got time for that.
So I modified my network driver to use one of the macaddrs that had internet access. When I needed something from the Internet, I'd load my modified driver then unload it when I was done. Much easier.
I thought I was doing it for such short periods of time that nobody works ever notice. Of course I was wrong.
After about a month I got called into the IT manager's office. And of course the the macaddr I picked belonged to the VP of engineering who also was the son of the president.
Fortunately they understood that young engineers are dumb and do dumb things and let me off with a warning.
Gives a whole new* meaning to “This program has performed an illegal operation and will be shut down.”
*Well new-ish. The first time I saw that message as a child playing a game on Windows I freaked out and immediately turned off the computer. I was terrified the computer did some illegal math and I was going to be arrested!
Nearly 150,000 children we're orphaned today when their parents were tragically lost in a catastrophic data importation process. Heartless DBA's were nonchalant as they spoke to the children of their parents being merely "redundant backups".
LOL... my mind went straight to "Two identical UUIDs were generated for containers running in a Kubernetes cluster which powers Chittatong's infrastructure, wiping out everything in the process".
I absolutely love industry-specific news sites / communities. Hacker News itself is one (duh), but to me it's most fascinating seeing "non-tech" industries have some sort of digital (or sometimes even a regular print paper, if it's niche enough) presence. Obviously it's not surprising when you think about it that an industry would have its ways to spread news -- but these industries are so out of my orbit that it's always novel to stumble upon.
Reminds me somewhat of getting two pieces of network equipment from a very cheap vendor that have identical Ethernet port MAC addresses. Have seen it more than once.
As I recall, the 3com 3c509 sold so many copies that they recycled MAC addrs and hoped that the old ones wouldn't collide with the new ones. I had a couple hundred go through my hands but never caught a duplicate.
I used to have a list of "bad" IMEI numbers and android IDs; there were some android phones where the whole run of that model would return the same identifiers.
If our code found one of those "bad" ids, we'd have to pick a new UUID to use as an identifier for that phone and save it to the flash.
There is also a brand of Chromebooks that an entire model run had the exact same serial # and machine ID. Same issue.
Years ago I made a large scale device data storage system, and one of the key design constraints I included that always threw people for a loop when they saw it was 'device unique IDs are not unique'. The system explicitly scoped all data in such a way that any collisions would always occur within a given customer that owned/controlled the device, to avoid data leakage, security issues, etc.
Because yeah, it's amazing the corners people will cut.
Last I checked, the system was still working well at 4+ billion devices, so I guess it worked out.
There is a long history of identifiers being reused in world shipping.
One of the staples of contracts class in the first year at many law schools is Raffles v Wichelhaus, an English contract case from 1864.
There was a contract for someone to sell a bunch of bales of cotton from India to a buyer in England. The contract called for the cotton to be sent on a ship called the Peerless to Liverpool from Bombay.
Unknown to both the buyer and the seller there were actually two different ships called Peerless both sailing from Bombay to Liverpool, one arriving in October and one in December.
They seller was thinking of the December one when signing the contract, and the buyer was thinking of the October one.
The buyer needed the cotton in October and when it did not arrive on the Peerless in October the buyer considered the contract broken and refused to accept the cotton that came on the December Peerless.
well you can’t stop halfway through the story. what was the outcome of the case?
Defendents didn’t pay for the cotton
https://en.m.wikipedia.org/wiki/Raffles_v_Wichelhaus
So Peerless wasn't really peerless afterall.
There's the beginnings of an Abbott and Costello skit here.
"I went to the pier to meet the Peerless but the cotton didn't appear"
"Did you talk to Captain Pierre?"
"Captain Pierre of the Peerless? No, the captain of the Peerless was Captain Pearce"
"Well did you talk to Captain Pearce?"
"Yes, on the pier." ...
That's strongly reminiscent of the old Two Ronnies sketch, about misheard orders:
https://www.youtube.com/watch?v=pV1IP4N9ajg
Even now "Fork handles" will get a smile from me.
I think you’re right. If we add in some business about a portly porter who departed promptly from the port to go to a party while we were peering off the pier waiting for poor Captain Pearce of the Peerless to put in an appearance, I can practically hear it in Ronnie Barker’s voice. He might be the only person who could actually get through the script without stumbling.
"I need some Os!" "No! Not hose! Os!"
My high school english teacher ordered something that had cardboard cut outs of the alphabet and when it arrived, a few of the letters were missing.
When she called the company to straighten it out, she said (calmly) that the packet was missing the F and G.
The woman on the other end gasped and said, "we're happy to send you a replacement letter, but there's no need to be rude!"
"LO! FUNEX?"
Sometimes I think there must be something wrong with my brain because for the life of me I cannot figure out what is funny about homophone jokes.
For me at least, the joke is obvious and not particularly humorous but the delivery by the performers is what makes it funny.
Exactly. Who's on first? https://youtu.be/nZ5vspsNS1g
You are not alone, I have often the same kind of reaction to play-on-words.
Let's see if you are sensible to other kind of humour :):
https://www.marriedtothesea.com/041508/tracking-number-14.gi...
And don't call me Shirley.
Naah... it was a peerless-to-peerless network.
You’d think serious contracts would normally have provisions that would require mentioning expected dates, since late shipments would presumably be a common occurrence you’d want all parties to consider explicitly.
Lessons from such cases(or case law) make one specify expected dates.
According to A.W. Brian Simpson, "Contracts for Cotton to Arrive: The Case of the Two Ships Peerless", Contracts Stories, p43,
> A contract for cotton "to arrive" was a contract for forward delivery, or, as it is sometimes called, a "time contract". One might expect that such a contract would normally specify a time for delivery. For it is the moment when the goods become available in the market that is of paramount importance to the purchaser, particularly if the purchaser wants the goods for use. But the world in which such contracts originated was one in which this was not really possible. Although one could discover, after an interval, when a sailing ship had left or, more approximately, proposed to leave its port of departure, it was very uncertain when, if ever, it would arrive at its destination. Even when it did arrive, there were uncertain delays in finding a berth to unload its cargo. Hence such contracts did not originally specify the time of arrival, much less delivery, even within some fixed period. All they did was to identify which shipment of cotton was being sold; presumably the rationale of this was that the buyer, so long as he knew which shipment was being sold, would be able to form his own estimate of the probable time of arrival. This would not, of course, be a point in time but a period. It is said that originally such contracts were made only when arrival was imminent, the ship typically having been reported off Point Lynas, which is on the north coast of Anglesey, some fifty miles from Liverpool. Presumably there was a signal station there. No doubt also cotton was sometimes sold as the ship lay in the river, waiting to berth. In such cases the date of delivery could be guessed with some precision, though a square-rigged vessel, if it did not employ a steam tug, could take a long and unpredictable time to cover even fifty miles.
The author also provides the broader context, which is that this was likely a form contract in the nascent commodity futures market. Additionally, this occurred during a period of particularly overheated speculation in cotton. In other words, just as is common today, financial speculators were pushing the legal and technological envelope of the instruments available to them. (Futures markets go back much further, but the mid-19th century is in many respects when modern futures markets began to take on their current shape. He cites another source pointing out that in "'in certain offices in Liverpool today the futures department is still called the Arrivals Department.'")
(IANAL)
Reading this case, I'm surprised at the outcome. The seller fulfilled on the terms of the contract.
The contract also didn't specify the precise color or weight of the cotton, the exact destination, etc etc etc so the defendant could make similar claims to renege on the contract.
Granted, time is arguably special inasmuch as it allows the seller to construct a scenario for fulfillment, e.g. the seller could've delivered 100 years later on a new boat that happened to be named Peerless. That's clearly not the intent.
In that sense, a contract can be considered void if it doesn't reasonably specify time.
> In that sense, a contract can be considered void if it doesn't reasonably specify time.
The judgment states pretty clearly that a contract is void if the two parties, at the time they made the contract, did not agree on what it meant.
> the moment it appears that two ships called the “Peerless” were about to sail from Bombay there is a latent ambiguity, and parol evidence may be given for the purpose of shewing that the defendant meant one “Peerless,” and the plaintiff another. That being so, there was no consensus ad idem, and therefore no binding contract.
[The words are from the defendant's lawyer, but the court appears to have agreed immediately.]
So this isn't formally a "win" for the defendant - formally, there never was a contract, and the suit was dismissed for failure to state a claim.
My point is that NO CONTRACT perfectly spells out every detail => this argument can be used to null any contract => weak legal reasoning. A buyer could make up any sort of nonsense to escape a contract, like (to pick a random example) arguing that a certain social media site has x% fake accounts.
Far stronger reasoning (for example) is that a contract must spell out time, which is a special property of contracts because (for example) 1000000 years is virtually never an acceptable period for which to fulfill on your end of a contract.
This isn't really how contract law works. There may be minor details that are not specified in the contract but unless it can be proven in court that those details were actually within the contemplation of one of the parties and connected to his or her decision to enter into the contract, their absence would not be sufficient to nullify the contract.
A contract is an agreement, so it stands to reason that if the parties do not, in fact, agree, there is no contract. The piece of paper we call a contract is, in fact, only a (strong) evidential tool to help the court figure out what the parties agreed.
> Far stronger reasoning (for example) is that a contract must spell out time, which is a special property of contracts because (for example) 1000000 years is virtually never an acceptable period for which to fulfill on your end of a contract.
How is this "far stronger reasoning"? It isn't even reasoning at all, because there is no existing rule that a contract must spell out time, so it's simply an untruth. Unless you were suggesting that the court create a new rule out of nowhere that all contracts must spell out the time for performance or else become void. A court would obviously never do that in light of the huge disruption it would cause.
Maybe when contracting with the devil?
I felt bad for the seller for a while. Then I realized they probably just sold the cotton to someone else, and that fungibility and liquid markets make a lot of this stuff less risky on both sides.
But the price was probably settled well in advance, so the seller was left taking on market risk, which depending on the way things went, could have been anything between a bad loss or a nice windfall. Less likely the latter, I would expect, since they were forced to sell the cotton in Bombay or cover the cost of transport elsewhere.
>But the price was probably settled well in advance, so the seller was left taking on market risk,
No. That was the whole problem. It was for market price when the cargo arrived and the price of cotton jumped between October and December. So the buyer didn't want it any longer and basically claimed they thought it was going to be on the October boat.
I think that all the analysis I've found with a quick search isn't very helpful.
The seller had to sue to either obtain payment or void the contract or else spend energies and time pursuing payment by persuasion whilst the entire time granting the ostensible buyers a free call option on FOB Liverpool cotton. My cynical guess is that regardless of evidence of foreknowledge about the duplicate ship names, Lloyds Register [0] most certainly did exist and importantly was considerably more accessible from Liverpool than India. Seller's imperative wasn't recompense but prior to marketing the cargo and taking profit, obtaining title and clean hands. Why go to so much effort? Letters of credit access and costs issues that could have been affected by a impossible distance impedance to necessary restorative PR.
[0] https://hec.lrfoundation.org.uk/archive-library/lloyds-regis...
Edit:.. evidence of foreknowledge..
I wonder how this has played out in the doubtless many other contract law cases. If this was really a case of (apparent) confusion on both sides, really not much hard/foul to either, so just void the contract. I assume you might see a different result if there was significant hard that fell disproportionately on one party.
If shipping was done under now void contract, will transport company be paid at all?
We encounter this all the time at work. New customer, so new integration. What's your unique shipment reference? This one? Ok fine. Go into production, and after a few months we get missing shipments. Support check, missing shipments have same reference as old shipments. "Oh, yeah we reuse the references after about 90 days... And, no, we don't have any globally unique references."
This is fun when so much of the flow is based on these references, think goods arrival scanning, and sometimes shipping does take a long time so 90 days or whatever is cutting it close.
Why would you ever reuse an identifier like that? Is there some kind of material cost associated with a new identifier?
This is what we've never understood. Trying to ask why is almost always futile, the people who're there now never knows.
I suspect it's often some legacy stuff, like a certain system only had 6 chars available for the reference, and so that's how they ended up working around it and nobody realized that limitation no longer exists.
But yeah, does not make much sense to us either.
Just like passenger name records - 6 characters for legacy reasons, so they’re constantly recycled
Is it a fully computerised B2B system? I mean when I order some patch cables for a project, I do it via a web shop and pay with my corporate credit card. The vendor generates an order number but also asks me for customer purchase order reference. I just make something up that might have my initials and date and a serial like "MV-20220723-1". Others may not be so methodical.
Yeah this is B2B, so should be computer generated.
Then again, who knows what goes on behind the scenes...
This reminds me of a project I was remotely involved with: Airbus having to handle an aircraft order number above 5 digits as they were delivering their 10’000th aircraft to a customer.
This was a multi year project where we had to deliver software used to map risk and impact across the whole company.
Imagine the costs.
source: https://www.flightglobal.com/airlines/a320neo-line-adapts-to...
Yeah I mean I also get that aspect. We integrate with many systems, we have 18 different integrations with one of our larger customers, and we're just a small piece of the puzzle.
Would likely be super costly just to figure out which, if any, of the systems that would have to change.
Even the USPS reuses tracking numbers. I had a package show as "delivered" before it even shipped once, because it received a recycled tracking number.
I don't even reuse references inside a single running instance of software. Using u64 you can generate billions a second and still not run out for hundreds of years.
Right, but u64 is kind of long for something you might want to read over the phone, or enter using DTMF tones.
USPS tracking numbers are at least 22 digits long (depending on shipping method; some can be 27); I don’t think ease of data entry was a priority for them.
22 digits and they somehow still manage to reuse tracking numbers. 10^22 (or 10^20, if we assume some encoding overhead) valid numbers should be able to uniquely identify a lot of mail.
They probably encode information in the code itself then, perhaps source/destination or similar. Perhaps to allow "offline" operations?
A lot of the first digits are actually used for parsing. It's not a fully unique number.
USPS labels (and other labels from other couriers) are an incredibly fascinating subject you would never care about until you work in the industry.
For the ones you mention that have 22 digits, the first 8 digits (if memory serves) identify the class of mail service and other metadata. So that leaves you with 10^14 at most, assuming there’s no encoding overhead / check digits.
> USPS tracking numbers are at least 22 digits long
Actually, that’s wrong. There are shorter ones.
Examples:
82 000 000 00 - Global Express Guaranteed
EC 000 000 000 US - Priority Mail Express International
CP 000 000 000 US - Priority Mail International
There’s also foreign shipped packages that will follow various standards that aren’t 22 digits, yet are still technically a valid USPS tracking number.
They might need a new type of identifier to guarantee uniqueness. And there might be cost associated with updating the system (workflows, databases, scanners, training, etc) to deal with new type of identifiers.
I'm thinking either production or the warehouse still uses manual stamping of lot (or shipment) numbers with those auto-increment stamps... The number is then captured by hand into a system somewhere.
The system worked fine when production was X times smaller, but no attention has been paid to it since it was first designed.
Some legacy identifiers come in fixed length fields, insufficient for contemporary usage. I know a company where some identifier should have been lengthened long ago, but that would impact a couple hundred systems (and by system I mean whole applications, front and back) - so they keep plodding on with what they have and yes, it is a drag on operations and it causes endless hacks.
I have worked for a company that reused order-tracking identifiers. The reason was mechanical: The more digits in the identifier the bigger the barcode on the shipping label. A non-issue with 2D barcodes but back then it was an issue.
In some cases it’s a flag that there’s a mainframe underneath that people are afraid to touch with the number of digits fixed to save memory. So many other legacy systems assume the field is fixed that you can’t add digits. Companies then look and say, “We can spend tens of millions of dollars to fix this, or we can spend the money on advertising and compensation, and just deal with the issues that come with reusing numbers”
Totally different context, but at my company, they started reusing some IDs that are supposed to be unique because they ran out of them and the old-as-fuck computer systems can't handle longer IDs.
Many airlines reuse your booking reference number too
Add shipping container IDs and ship IDs to the list of annoying human-oriented numbers that you can't assume are unique. :P
Another fun one is our customers which are close to the border. Sure a truck's ID (plates or similar) certainly definitely unique, but if the other warehouse is close to the border as well they can make multiple trips across the border in a day... Good times when that truck ID alone is used to trigger business processes.
Information should depend on the key, the whole key, and nothing but the key, so help me Codd!
>"Oh, yeah we reuse the references after about 90 days... And, no, we don't have any globally unique references."
The minute a simple unique identifier is established for something, someone who is just important enough not to be told "no" screws it up.
A thing that I've seen is that people want things to be grouped together in reporting, so they insist on it having the same identifier as all other things in the same group.
Sooner or later, they ask for a report that distinguishes between them, though.
> Consequently, as there was no consensus ad idem ("meeting of the minds"), the two parties did not agree to the same thing and there was no binding contract ... therefore, the [buyer] did not have to pay.
The manufacturer reused identifiers (5 to be precise) in a later batch. This was a manufacturing error rather than a freak collision.
Edit: Source https://www.thedailystar.net/business/news/two-containers-sa...
"Five containers of the second batch have numbers akin to another five belonging to the previous batch, according to Borhan."
Whenever I see somebody detailing the scope of a mistake at their business, I mentality add the words "at least" to any quantities.
I add it to the person instead.
"Five containers of the second batch have numbers akin to another five belonging to the previous batch, according to Borhan, at least."
This is much more reassuring because it just looks like Borhan needs to get his shit together. Optimism!
Glad to finally see https://container-news.com/ hit the front page on HN
Wrong containers!
Still good lesson learned.
This is legit one of the things I love most about HN, articles might be 80% about tech, but the content in the remaining 20% can be about pretty much anything, and it's always fascinating to get insight into other domains. Never considered that containers were numbered, let alone that a number clash is a significant incident, but thinking about it, yeah it makes sense.
This is kind of what big chunks of the internet were like back in the late 90s, very early 2000s, particularly before smart phones.
I suspect it's tied up in the shift of quantity/scope of "user generated content". News articles and blog-posts etc. got somewhat pushed out by "look at this cute cat photo I allegedly took myself", etc.
as HN evidences, this stuff is all still there (possibly more than ever), it's just drowning in an ocean of content aimed at pleasing children, Google's algorithm, and the less intellectually-inclined
> big chunks of the internet ... particularly before smart phones
Then, IMEI numbers.
Maybe a rare opportunity to plug one of my favorite non-fiction books, The Box, about how shipping containers restructured global trade.
https://press.princeton.edu/books/paperback/9780691170817/th...
Thank you for mentioning this book!
And much more than trade. It had effect on road infrastructure, various temporary constructs including school rooms for emergency situations and housing as well.
And product dimensions, e.g. for aircraft, cars, military equipment,... Being able to ship in standard containers makes a lot of things so much easier
surprised but really not to see people so passionate and dedicated to containers. warms my heart, really best thing to ever happen.
It sounds like the actual unique number is only 6 digits long and chosen by the manufacturer, so it could either be a mistake or identical randomly generated numbers. My math is a bit rusty - how you you solve the birthday problem for 1mil instead of 365?
https://containertech.com/articles/shipping-container-number...
https://en.wikipedia.org/wiki/Birthday_problem
Cheap approximation is square root.
Yep, and it's pretty close in this case: for a 50% chance, a sample of 1178 containers with 6-digit numbers (assuming a uniform distribution) would suffice.
Using the formula on wikipedia and checking random numbers it looks like the number required for 50% chance of collision is around 1200.
https://www.wolframalpha.com/input?i=1-%28999999%2F1000000%2...
https://en.wikipedia.org/wiki/Birthday_problem#A_simple_expo...
I think you meant to link to 1-(999999/1e6)^(1178 choose 2) [0]
[0] https://www.wolframalpha.com/input?i=1-%28999999%2F1000000%2...
It’s worth noting the full number isn’t just the six digits (plus checksum) but the full number including the letters that indicate owner and type, so a single owner wouldn’t give two of their containers the same number.
That said, how many containers is one company likely to own? 1,000,000 is a big number but it seems like some of the big logistics companies could flirt with that. Doors anyone know if they have multiple “owner codes” or an I just way overriding the scale here?
> Doors anyone know if they have multiple “owner codes” or an I just way overriding the scale here?
Like IEEE OUIs, one company can have multiple owner prefixes. Maersk has 41:
* https://www.bic-code.org/bic-company-search/?searchterm=MAER...
* https://en.wikipedia.org/wiki/ISO_6346
Right. So what happens when we face container number exhaustion and we found out that some C developers have been using char id[12]?
I suspect they’ll move to Container.v6 and that everyone will dislike because the values are harder to read to say… then the industry will take an additional decade or two to actually start to use it.
We are approaching decade 3 of ipv6 and ipv4 is still the majority of internet traffic.
Being a bit more kind, ipv6 only really started to get moving in the wild around ~2010 so we are at the start of the second decade. It has climbed steadily since this point and will be the majority globally within a couple of years. It is already the majority of traffic in the USA, Germany, France and India.
> […] ipv4 is still the majority of internet traffic.
Not if you're on mobile. Lots of cell networks only give IPv6 addresses to phones.
E.g., T-Mobile in the US:
* https://www.youtube.com/watch?v=nNMNglk_CvE
People will have to upgrade by the deadline. This is not unheard of (2004):
> Recently the Uniform Code Council (the organization that governs UPC bar codes) announced that starting in January 2005, they will require that all retailers and trading partners in the United States and Canada that presently scan 12-digit UPC bar code symbols be capable of scanning 8 digit EAN-8 and 13 digit EAN-13 bar code symbols as well. Furthermore, the UCC strongly recommends enhancing systems to accept bar code data of up to 14 digits in preparation for a new numbering system called GTIN (Global Trade Identification Numbers) that will eventually be used to identify products world wide.
* https://www.taltech.com/blog/post/changes_in_the_upc_code
* https://en.wikipedia.org/wiki/Universal_Product_Code
* https://en.wikipedia.org/wiki/Global_Trade_Item_Number
Sidenote: it would be interesting to see what would need to be done to expand the allowed telephone number length:
* https://en.wikipedia.org/wiki/E.164
Maersk has a capacity to ship 4 million containers at once. I suspect you’d generally have 3-4x that many because they spend a lot of time waiting around and also just pile up in Los Angeles because no one needs to ship (as much) stuff back to China.
It's a mistake. They keep track of numbers they've already used, but in this case failed to do so properly.
1178. This is actually part of the base stats package in R:
See https://www.rdocumentation.org/packages/stats/versions/3.6.2...
Here's the derivation of a formula by Matt Might
https://matt.might.net/articles/counting-hash-collisions/
You can approximate the birthday paradox by taking the square root. So 1mil gives you ~1000. 365 is ~19 (the actual value is 23).
When I worked at Amazon we found two NICs with the same MAC address.
And that was a long time ago with a comparatively very small server count compared to today.
Someone's manufacturing database probably had a tiny race condition.
I used to work for a company that sold labels for various third party printer manufacturers, and let me tell you, some of them were VERY lazy when it came to assigning MAC addresses.
yep, not unheard of for cheap unbranded devices to all have the same MAC, unfortunately.
MACs are supposed to be globally unique, but they only really need to be broadcast domain unique, so you can get away with using the same MAC for a lot of devices as long as most people don't use two on one LAN.
I'm aware; that really doesn't make this excusable practice though.
I worked for a company that made a networking product and we managed to build 1,000 units with the same MAC address (we had a big block of assigned addresses) because of a miscommunication with the vendor who provided the preprogrammed microcontrollers..
Luckily the MAC was in a rewritable location so it was possible, if a royal pain in the ass, to reprogram them all.
20-odd years ago, the college I attended (and worked for) was outfitting one of the computer labs with new network cards; migrating from Token Ring to Ethernet as I recall. To do this, 3COM cards had been bought by the boxful.
We replaced all of the cards, and booted the lab. 1 machine got an IP and then it all went to hell. Every single machine showed up with the same MAC. Think we had to rip and replace to fix it.
I'm having trouble finding a reference just now, but the MAC address for a modem-based link on Windows had "DESK" until it started causing real trouble. And one of those problems was that GUIDs were obtained by using "the MAC address" of the PC as an input to a DEC-Intel-Xerox-Microsoft algorithm. Around the time of this coming to a head, it came up that some manufacturers were out of MAC addresses for whatever reason, and also that some manufacturers were assuming that two random NICs on an Ethernet would not both be one of $MANUFACTURER's cards, so care was not necessary.
Worked for a small ISP in early 2000s. Not every new customer had an ethernet card in their PC and we had problems like installation crews calling the office that there is no port to stick the cable in.
The company obtained 300 cheap Intel PRO/100 Fast Ethernet NICs from China. The idea was that the crews would have a bunch of those cards to be able to install them in customers' computers.
Everything was dandy until second installation in the same building. For a little more backstory - it was a kind of shitshow infra with dumb switches and all customers in a building being in the same LAN.
So... the second installation in the same building rendered the former newest customer's link inoperable. Or wouldn't work, then suddenly there was connectivity, then there was no ping to the gateway but some other devices were pingable etc etc. The crew replaced the card with another one (from the same shipping), re-crimped RJ45s on both ends, changed switch port and nothing - same shit with random internet connectivity losses. Weird situation with seemingly no reason for what was happening.
It later turned out that the reason was that all 300 NICs had the same MAC address. All of them.
The container in question is SLHU4500470. The first four characters are the owner, the next 6 digits are the unique (per owner) number, and the last digit is a check digit.
Somehow I always assumed there'd be more than 6 digit IDs for these things. I'd guess collisions have happened, but never been caught in the same port before.
What happens when somebody has more than a million containers? 6 digits doesn't seem enough to guarantee uniqueness.
You assign a second owner number to the group, probably
There's only about six million active containers in the world. If one owner has more than a sixth of them, an easy fix would be to issue them a second owner code, basically extending the six-digit field by a bit.
> There's only about six million active containers in the world.
Huh, that's a lot less than I expected there to be.
Though that's about 1 per 1000 people, and if you imagine how much stuff you'd end up with using all that a container could carry when constantly in use, I guess about a thousandth of that isn't too weird an amount.
6 million seems like a underestimate. There are meant to be 54k container ships in the world. That would mean an average of 110 containers per ship, and ignores all of the ones in use on land. Some of those ships can carry 24k containers _each_.
There are not at all a vast number of 8,000 TEU+ ships however. Small enough that any one ship owning company might have a few dozen at most. Evergreen says it has something like 150 ships.
Evergreen is still growing, though; They've got several 8,000+ TEU ships set to launch in the next few years. Consolidation is key.
I would guess that the next answer is "Evergreen gets multiple Owner codes", because that's a real simple way to stretch it, but...
Wikipedia says 20.5 million _in 2012_ https://en.wikipedia.org/wiki/Cargo_container
This was their source. Apparently not updated since that 2012 survey: https://www.csiu.co/resources-and-links/world-container-flee...
Well, we'd probably just switch over to UUIDs since those things are practically infinite and we've now got a lot of well established infrastructure in place for handling them.
Nope, that many characters would be impractical in daily use. There’s a lot of copying, pasting, reading, and reciting of numbers via email/web/phone/TMS/WMS/etc.
Ahem, 10 million
The 7th digit is a checksum digit, as previously noted. So only 6 "free" digits so a million is correct.
You can read more about the container numbering standard here: https://en.wikipedia.org/wiki/ISO_6346
Thanks for the info
Like IEEE OUIs, one company can have multiple owner prefixes. Maersk has 41:
* https://www.bic-code.org/bic-company-search/?searchterm=MAER...
* https://en.wikipedia.org/wiki/ISO_6346
I always wondered if this was designed to integrate into the existing railway numbering system. In the US, at least, owner identifiers are pretty consistently 4 characters or less, and individual unit numbers are 6 digits or less (i. e. BNSF 123456).
I believe the 4th character of a container ID is always a U, so the container owner is the first 3 characters.
U is code for freight container so yes :)
> “I have never seen two containers carrying the same number in my 27 years of career in the shipping sector,” pointed out Mohammed Abdullah Jahir, chief operating officer of Saif Maritime Ltd, adding that such an incident cannot be detected unless the boxes arrive at the same port at the same time.
If the port authority conducting the inspection are not diligent, it's easy to miss this.
I worked at a small "automall" of several dealerships. Our system operated inventory numbers based on the last 6 digits of the vin#. Sounds like with 1 million options, you'd be fine. It didn't take long for duplicates to start coming up when you have hundreds of cars in stock, and sell hundreds a month. Let alone the problem with a car being sold new, and then being traded back in. That was fine, because we had a different leading digit for new vs used. But you'd be surprised how often a used car gets sold, and then traded in again at the same place. Now what number does it get? The same one. Fine, atleast they're not both in stock at the same time. Great. Sell it again. Then when a customer calls six months later, try and lookup the deal your most common way... Oh ya.. now I've got 4 possible deals for this car.
Haha. It’s like Hacker news AI that votes things up saw container and port and decided it’s a great devops story from Bangladesh.
I wonder how common actually duplicated serial numbers are in various things. In some cases they do matter, but in many others not really. Think of the non-smart devices.
And it can often be simple human error. Some fat fingers the wrong range in morning, forgets to list the used codes, reads the wrong line, some glitch preventing machine from saving the last used code...
Just remember how much stuff is made by cheapest possible bidders, who might not be so much interested to deliver best work always.
Somewhere I worked used the wrong serial numbers of postal delivery. We had an overflow which no one noticed for about a year and we ended up using the same range as another customer of the postal company. There were thousands of parcels with duplicated serials, everything arrived fine and as far as I know there's been no real admin issues either. So in this case it didn't matter.
Obviously one of the two containers traveled back in time. Don't let them touch.
They are the same container but the entropy is reversed
Can someone please explain the significance?
Between oops and sus.
In this case, it appears to be a mistake. That a number was accidentally reused.
But a concern could also be fraud, theft, smuggling, etc. A “bad” container that was supposed to fly under radar mocked up to look legit if anyone checked.
Annoyingly, the top image is of some random containers, and not of any of those two. This is just dumb and useless.
This seems indicative of a security concern. When this happens it could indicate someone is trying to get a container full of e.g. explosives or chemical weapons to be shipped to a target city without a paper trail. Imagine if the malicious container had e-ink screens on the outside that allowed the numbers to be changed on the fly to route the container through multiple untraceable steps. :(
Just yesterday I was reading about Time-of-creation/Time-of-use (TOCTOU) race conditions in symlinks (https://lwn.net/Articles/899543/).
The manufacturer's new container-id generation logic probably has/had this category of issue (i.e., TOCTOU).
While TOCTOU is used to describe the problem encountered by software in general, an almost identical problem in lock-free data-structures is called the ABA problem.
https://en.wikipedia.org/wiki/ABA_problem
I always wondered if there isn't someone out there making dodgy devices with mac addresses in someone else's range.
Many years ago I encountered cheap knock-off network cards¹ that had default MACs in the range of a big known name brand, and as far as I know it wasn't some cross-branding/affiliate/other deal. So yes, there has been and no doubt still is.
[1] in fact, back in my student days most NICs I had were cheap knock-off versions, the "real" things were not the inexpensive items they are today. This predates it being common to have one built into your motherboard, even more expensive ones, by some time.
Several years ago I worked for a company that made a usb+network and usb-only skew of their product. The usb-only boards were the same as the usb+network boards with a few parts not populated.
We started getting tech support complaints when we sold the product into China. Turns out, an enterprising vendor bought a single usb+network printer, desoldered the EEPROM (containing the ethernet mac address). Then that vendor bought usb-only (cheaper) products, added the additional parts and bulk copied the single eeprom image (with the mac address) onto the new products, selling them as the more expensive usb+network sku. Result: a dozen+ of our product running on the LAN with the same mac address.
Sorry to side-track this, but does anyone know if there is a reason why we make homophone spelling errors? Do we sound words out as we write them? Neurologically, what is happening? It doesn't sound automatically the case that the pathways for concept -> word -> write actually flow through a concept -> word -> sound -> write path. It's not a confusion of the word since this user clearly knows SKU is not SKEW.
And /u/linuxlizard, if you don't mind saying, were you using speech-to-text to write that comment?
A decent proportion of the population frequently run internal monologues in the voiced manner - when I'm typing this out I can hear (not actually hear but mentally hear) someone speaking the words as I type. I assume the frequency of homophone typos are due primarily to this - since both skew and SKU are identical in my inner monologue and I'm trusting my fingers to choose the right combination.
I think homophone spelling errors are a different issue though - english education in the US is really quite poor so a lot of grammatical rules[1] (they're/their/there) and spelling aren't really well impressed on society at large - people will hear a term in conversation and start using it in their own speech, when they arrive at typing it out they'll make their best guess at spelling and it'll probably end up a roll of the dice which homophone their spell-check ends up shoveling them towards.
1. /me types while admitting they constantly type in spoken english - preferring the spoken sentence construction rules. Something something glass houses and stones.
Thanks for answering. Of course, I have the opposite of your second sentence, mispronouncing words I've only ever read :)
Ah, I still internally mispronounce Quay - no matter how hard I try and relearn it as KEY.
> english education in the US is really quite poor so a lot of grammatical rules[1] (they're/their/there) and spelling aren't really well impressed on society at large
This is false. It was impressed into us many times throughout grade, middle, and high school. People just don’t care enough to get the right spelling because they were using the words natively long before they learned to spell them.
Backing this up- I see that complaint all the time about US education, but I know me and all my peers had this impressed on us throughout our (public) schooling. People just don't care because to them, the word is right but the spelling part is a formality that can be ignored.
For what it's worth, I started making homophonic spelling errors after my English improved.
I wonder if I'm unconsciously mimicking errors from others, or if something in my brains has changed.
SKU Stock Keeping Unit. Sorry. Vs Skew. I probably am using the word "SKU" wrong but it's what we called the slight variations of product.
https://www.investopedia.com/terms/s/stock-keeping-unit-sku....
No no. I know what you meant and it's a harmless typo obviously.
Typos are what happens when I post too quickly while waiting for my app to boot.
Many years ago I worked for a major cellphone service provider in Europe - cellphones with duplicate IMEI numbers were an issue (the IMEI number was meant to be unique per cellular device much like a MAC address). This occasionally prevented an IMEI block on a stolen phone.
IIRC that's what some manufacturers did. However, rather than squatting in someone's existing range, they ended up squatting in unused ranges that were unlikely to be assigned anytime soon (back in those days the assignments were sequential). IEEE ended up cracking down on this by randomizing OUI assignments.
Years ago I bought a bag of Bluetooth 4.1 USB dongles for development only to find every single one of them had the same MAC address. Ugh.
Well, there’s a ton of people using Xerox’s 00:00:00
The global platform which should solve the issue is opt in for container manufacturers, not mandatory https://www.bic-boxtech.org/
A tragic day for all my fellow containerheads.
Those containers are going to be worth so much on the collector's market though. Like that stamp with the upside down plane on it.
This is horrifying.
Could you explain why?
A real-life UUID collision
Not that terrifying when humans are involved… assuming competence
Assuming competence with humans involved is terrifying
Why?
It’s an identifier collision, they’re supposed to be unique. That’s what did SHA-1 in.
SHA-1 is a hash function. What did it in is that there was found a way to make different strings hash to the same value. This is just someone accidentally re-using serial numbers, it's not a weakness in some algorithm.
What's really horrifying is this: "such an incident cannot be detected unless the boxes arrive at the same port at the same time"
So they running this port with pencil and paper? No database? No sanity checks?
>So they running this port with pencil and paper? No database? No sanity checks?
Or they simply don't run those queries until they need to. i.e. "we don't give a F unless there's a hiccup"
The point isn't to track containers. The point is to get goods to where they need to be and when. Unless two of the same container shows up thereby causing a WTF moment there is no problem because there is no ambiguity in the container handling process and therefore they don't care.
Or each port does have it's own database, and so they can only notice a collision when two containers with the same ID show up at the same time?
It's not like Bangladesh and Port of Los Angeles have a need/desire/whatever to share the same primary keys in the same database somewhere.
How do you know this container isn't the same one you saw before? You need to have them at the same place at the same time to know they're the same container.
Computers with business logic. It can't be the same one if it travels faster than is possible. And anyway, if they were being tracked ...
The terminal doesn't always know the destination. Why would it? And anyway, intended destinations can change.
Suppose you were the guy who goes around numbering containers to begin with.
What are you going to use, a laptop or something?
If it ran out of power without completing its process, upon reboot it might very well assign the same number to the next container.
Even without a computer, you could have the day shift actually paint the number on the first container, but fail to finish the paperwork or it could get lost.
Then the night shift comes along and uses the same number on the next container.
I don’t see how a database (which they’re probably running anyway) would help, unless it’s connected to all other ports in the world an cross-examined for duplicates.
Which sounds like a lot of work and I’m not sure port operators want to share that, although it would be really cool.
They should use a blockchain!
I’ll see myself out…
It has been proposed in all serious several times - and then immediately the person proposing it was tarred and feathered, then disappeared by the relevant jurisdictions security services (only half kidding). I'd give you their names, but for some reason men wearing sunglasses and sitting in a van appear outside my house every time I consider it.
It’s probably people who think we don’t need gigawatts for a distributed ledger.
While they might consider THAT true, I suspect it has more to do with being able to track which companies and countries are doing what business with whom everywhere - especially if that includes countries they aren't supposed to be.
Tracking containers port to port everywhere would be a MOUNTAIN of useful intel.
Containers are already tracked. There's literally nothing stopping you from saying that container X is going to Italy when, in fact, it's going to Iran. Blockchain isn't magic.
Immutable ledgers only provide value when someone wants to fudge values. A unique constraint in a relational database can identify mistakes just fine.
As long as you trust the owner, administrator and developer of the database. I wouldn't.
Instead you trust the developer of the blockchain and of all the apps required to write data to and from it.
Because blockchain. Even though there are now dozens of instances of crypto developers messing up their own work.
Yes indeed, trusting something I can see and compute myself instead of trusting someone's promises. There's no way blockchain will ever be worse than just having to go along with it because there's no way to verify.
> I can see and compute myself
What exactly can you see and compute? The end result in the blockchain is the output of <something>, where <something> is any number of centralized actors putting data from opaque sources based on extremely complex contracts.
Run Postgres yourself. If Postgres developers are going to compromise their own software, it isn’t going to be to mislabel your shipping containers.
Most of the info in databases is boring and nobody cares about maliciously changing it it.
If someone were really interested in changing the number on your shipping container, blockchain can’t prevent someone with a $1 can of spray paint from changing it.
Then others have to trust me.
> spray paint
Sure, but the point here is to not lose the records too, which someone could trivially change if they own the Postgres DB. When I have a shared record of a container and somebody repaints its SN, at least I know I lost it, and I can also easily claim that I did not forge the records too because they signed the record with their wallet.
I worked in Bangladesh for 3 years, and it is such a land of contrasts.
The main electricity supply company at the time was running manual billings from a big room filled with manual general ledgers, one “T” account per household.
It is a humbling, impoverished country with its main riches being its resilient, kind, resourceful people.
Down the road/bay from Chittagong are the shipwrecking yards - a big time investment but worth watching is this… https://youtu.be/5jdEG_ACXLw
<edit> the film I am looking for is Iron Eaters, a very human view of the horrific shipyards. The above film is from India, but still worth looking at.
Thank you for the link. I just watched it in entirety. It's slow moving but well worth it. It's about a world I did not know existed.
The National Film Board of Canada is one of that country's most culturally valuable assets.
Very watchable indeed. Great stuff!
No it's not lmao
>Salam said that it is not possible to identify the number of boxes with double-up numbers without the report from the Chinese manufacturer.
Sounds troubling.
I understand that ports don’t share container info with each other and manufacturers don’t have a crystal ball to see all container IDs of a given customer but given that first 3 chars identify a shipping company, I have hard time understanding how the shipping company failed to catch this. How did they manage to create two waybills for two containers with the same serial?
Generating a waybill raises exception. It is Friday night and everyone else is already at the bar. Drop the unique constraint and call it day.
Ok but still: as a user, how do you even know that there are two containers with the same id? In other words, a human needs to have way of telling them apart.
Even if two entries showed up with the same id, I’d assume as a user it’s a glitch and would not put two different shipments into what I would assume is a duplicate entry for the same container.
I'd assume the containers were labeled at different ports and by chance got sent to the same port. So the persons looking at the containers only had one to worry about. And with both going to the same destination one person probably shrugged when they saw the origin port was somewhere else.
I don't know anything about shipping containers but I'd assume that the container owning company had the two doppel-containers enter service at different times and/or locations and their asset database either isn't centralized or isn't de-duped.
I’ve seen this type of thing happen a few times. Usually a combination of a human error at the factory plus flaky backend systems that like to do upserts.
Sounds like the setup for a William Gibson novel.
And it's on cases like this you discover your (theoretically) unique DB key isn't
Either this is a legit warp in the space-time continuum, or it simply is what it is.
I do not understand why they are not using solutions to this known problem?
If it is just a matter of unique identifier, a UUID4 or similar could be used.
I guess that they need some control digits, there are solutions for that too.
Is Frank Sobotka wanted for questioning? Or is Ziggy more likely to blame?
So, if I understand things correctly, the root cause of the global shipping meltdown is that someone used that field as a database primary key?
Maybe relevant:
https://youtu.be/BSe9JDVczUc
Containers are at play here.
Forma single case spotted out, i wonder how many other cases can be found with a thorough worldwide investigation.
Should've just used UUIDs, could probably turned all of Earth into containers and not had a collision.
Not should’ve, definitely would not have had a collision.
Ooof. dockerd is gonna be _pissed_.
As Cory Doctorow once said, “It is only a matter of time before a computer kills us.”
The minute I started reading I was waiting for the phrase "made in China" to appear. It's in the 7th paragraph: " M Salam noted that the mistake occurred when containers were made for Sea Lloyd in China."
I'm surprised it was "buried" that deep.
Something like 97% of shipping containers are made in China. This is presumably not lost on regular readers of container-news.com.
So a bit of a paint on container is used for routing? How feasible it is for criminals to repaint number on a container enroute to divert it and therefore steal its content?
Playbook on how to handle a uuid collision
But what does this have to do with docker?
;)
Why is this a big deal.. a signal of the end of the world perhaps? Or nefarious forces at play?
It’s like having two cars with the same plate
Isn't it more like 2 cars with the same VIN? The plate in this analogy would be the seal.
Sounds like it, but I’m still interested in finding out how big a deal it is. A quick search shows that there have been cars found with duplicate VINs and making a container with the same serial number seems like pretty pedestrian crime in comparison. That is not to say that this is a crime, could just be plain old manufacturing mistakes and it’s also obvious that not all container management systems check for it (even if it did, unless both end up in the same registry it won’t matter anyway).
It’s not a big deal per se but is a sign of a potential big deal. Or a minor f’up
I have a custom license plate on my car in my state. A friend of mine told me they saw the same custom license plate on the same vehicle make/model in another state. The only bummer was that that car's color was red, whereas mine is yellow. So two cars with same plate is totally doable if issuing authorities are different. Two cars with same plate from same issuing authority, that's the problem
There are special cases where two (or hundreds of!) cars can have the same plate.
https://patch.com/img/cdn20/getty/22887410/20200526/033010/s...
https://www.thedrive.com/content/archive-images/ap_111036136...
oh no! now how will they track us!!
Unless that number is the only thing they're using to route the container, it's more like having two guys named "Joe".
> _3u10 - It’s like having two cars with the same plate
I wish I could have the same plate as everyone else... or no plate at all like Steve Jobs used to do (https://abcnews.go.com/Technology/steve-jobs-car-apple-ceo-l...).
This is a completely different issue.
I imagine it would be a bigger deal if they had the same seal. _That_ would suggest someone was trying to steal cargo, or commit some kind of customs fraud.
What are the odds?
100%
More like 98%. There’s a chance this article is satire. It certainly reads like satire.
Meh? Maybe the customs should stop caring.
Dexter?
Imagine if software engineering ID allocation failures made frontpage news in the trade press.
"An object reference was discovered to be null today in a web browser window in Frankfurt. Officials said the problem was discovered when some JavaScript application code attempted to read a property from the object reference."
Funnily enough it was probably a crash in some system that generates the numbers, that caused the duplication.
I just had the very same thought reading the article!
"An admin at a local it shop discovered two 3com nics with the same Mac address while setting up a rack of four new servers. The admin got suspicious when reliable network communication was not possible with any of the two servers and after further investigation found the duplicate addresses."
This would only be discovered if two nics with the same mac addresses arrive in the same shop at the same time.
I'm not sure if your quote is from personal experience but... and this is totally cliche from the era... I was setting up a Beowulf Cluster made up of salvage 486s in the early 2000s because why not? We were running into some really bizarre issues, and eventually we got down to the just pinging the machines from each other and started discovering that when we went to ping one of them, we would get two replies!
Sure enough, two generic NE2K NICs had duplicated MAC addresses!
Beowulf Cluster. I just died and woke up in the 90s
Naturally, it started as a joke. My buddy had a pile of machines that the school board had decided to throw away. Being avid /. fans, I of course said “can you imagine a Beowulf cluster of those?”
So then it’s 2am and his basement closet is really warm…
Ha, yeah. I had the same experience, around the same time, also on a Beowulf cluster.
I've had this problem in modern times where, when setting up Windows PCs (via WinPE at our enterprise) some NICs would very occasionally not work right with the provided driver and end up with some default MAC.
Doesn't work out so well when you have a room full of these PCs all getting imaged at thhe same time and suddenly half a dozen on the same switch have the same MAC. :\
(I believe it came down to a BIOS problem and a new version sorted it out.)
In the late 90s I worked for a company that was afraid of the Internet. They had one computer in a common area that had access to the Internet but not the company's internal network for the ~50 engineers to use.
The internal network was coax Ethernet. I was working on a networking project at the time and ran a packet sniffer on the internal network and saw that some MAC addresses could access the outside world.
I'm lazy and I didn't like having to go halfway across the building, sit at a slow ass computer to download a datasheet, copy it to a floppy, then walk halfway across the building back to my cube, and finally copy it to my computer. Ain't nobody got time for that.
So I modified my network driver to use one of the macaddrs that had internet access. When I needed something from the Internet, I'd load my modified driver then unload it when I was done. Much easier.
I thought I was doing it for such short periods of time that nobody works ever notice. Of course I was wrong.
After about a month I got called into the IT manager's office. And of course the the macaddr I picked belonged to the VP of engineering who also was the son of the president.
Fortunately they understood that young engineers are dumb and do dumb things and let me off with a warning.
On the contrary, I think you did a smart thing.
Gives a whole new* meaning to “This program has performed an illegal operation and will be shut down.”
*Well new-ish. The first time I saw that message as a child playing a game on Windows I freaked out and immediately turned off the computer. I was terrified the computer did some illegal math and I was going to be arrested!
Like a new (std::nothrow) meaning!
... I'll let myself out.
me too!
Reminds me of this part of Wes Borg's "Welcome to the Internet Help Desk" routine:
https://youtu.be/1LLTsSnGWMI?t=240
That routine is so old, the last time I saw it I downloaded it over Napster and opened it with realplayer
Yup. But still funny as hell (if you ignore the references to dated tech).
Reading your comment. I had "PC LOAD LETTER" jump to mind.
I learned that PC in this context means “paper cartridge”.
More likely to be undefined, not null.
Or:
Nearly 150,000 children we're orphaned today when their parents were tragically lost in a catastrophic data importation process. Heartless DBA's were nonchalant as they spoke to the children of their parents being merely "redundant backups".
LOL... my mind went straight to "Two identical UUIDs were generated for containers running in a Kubernetes cluster which powers Chittatong's infrastructure, wiping out everything in the process".
They do sometimes :)
https://news.ycombinator.com/item?id=13713480
The best part for me was discovering that a site called "container news" exists.
I literally looked at the domain and exclaimed out loud "container news dot com?!?!?!"
And it has an app!
This website actually has some pretty good news too. Didn't know protests/strikes were still happening around California.
I absolutely love industry-specific news sites / communities. Hacker News itself is one (duh), but to me it's most fascinating seeing "non-tech" industries have some sort of digital (or sometimes even a regular print paper, if it's niche enough) presence. Obviously it's not surprising when you think about it that an industry would have its ways to spread news -- but these industries are so out of my orbit that it's always novel to stumble upon.
e.g. Freight Trucking is one that has a particularly robust network of competing news sites https://www.freightwaves.com/news/category/trucking, https://www.ttnews.com/, https://www.thetrucker.com/
To anyone else who finds this interesting, and I'm not exaggerating, -- if there's any cool industry hubs you find, please send them my way.
I'm trying to build a library of niche news websites. Thanks for these.
what hubs are you interested in?
Is it public?
Check out https://www.youtube.com/c/WhatisGoingonWithShippingwSalMerco...
https://gcaptain.com/
I like GCaptain. It’s shipping news in a nice format. Started reading it during the Suez blockage.
Almost makes me wish I worked in that industry. Logistics, especially when ship borne, is rather interesting.
Reminds me somewhat of getting two pieces of network equipment from a very cheap vendor that have identical Ethernet port MAC addresses. Have seen it more than once.
As I recall, the 3com 3c509 sold so many copies that they recycled MAC addrs and hoped that the old ones wouldn't collide with the new ones. I had a couple hundred go through my hands but never caught a duplicate.
I recall this. I called it Metcalfe's Law.
I used to have a list of "bad" IMEI numbers and android IDs; there were some android phones where the whole run of that model would return the same identifiers.
If our code found one of those "bad" ids, we'd have to pick a new UUID to use as an identifier for that phone and save it to the flash.
There is also a brand of Chromebooks that an entire model run had the exact same serial # and machine ID. Same issue.
Years ago I made a large scale device data storage system, and one of the key design constraints I included that always threw people for a loop when they saw it was 'device unique IDs are not unique'. The system explicitly scoped all data in such a way that any collisions would always occur within a given customer that owned/controlled the device, to avoid data leakage, security issues, etc.
Because yeah, it's amazing the corners people will cut.
Last I checked, the system was still working well at 4+ billion devices, so I guess it worked out.