Man, similar story. Spent a few months next to a mall parking lot with rough asphalt. Apparently the neighborhood had a car drifting crowd, and they'd regularly do so, which made me irrationally angry.
I only realized later that all the black dust everywhere must have been tire particles, when I realized other places DON'T have the black dust. Given the toxicity of tire pollution, it doesn't seem like my reaction was irrational after all. Sucks for all the people that still live there, who may not even realize what's going on.
It did glide briefly, the glide path took it directly into a school building.
Right after takeoff at low altitude is basically the worst place for this to happen. Speed and altitude are low so gliding is going to be a short distance and happen quickly.
If there had been a perfect empty long flat grass field in that location it may have been salvageable, but also right after takeoff the plane usually has a heavy fuel load which makes for a much riskier landing.
Edit: This article has a map showing the glide path:
They only ever got a few hundred feet off the ground.
Yes of course the plane glided once the engines stopped, producing thrust, just like all planes do. But just like all planes, and all gliders, gliding means trading altitude for velocity - giving up precious height every second in order to maintain flight. At that stage in the flight, they just didn’t have enough to give. If the same thing had happened at 30,000 feet, it would be a non-event. They would glide down a few thousand feet as the engines spool back up and once they return to full power, everything will be back to normal. Or if for some reason, the engines were permanently cooked, you’d have maybe 20 to 30 minutes of glide time so you’ve got a lot of time to look around and find a flat spot. But you just don’t have enough time for all that to happen When you’re a few hundred feet off the ground.
I’ll take this as an honest question. The simple answer: too much mass, no clear landing path, not enough speed or altitude to turn to find one and glide to it. In short, not enough time. Once the engines cut, that thing probably dropped like a brick.
Impossible. Low and slow conditions with insufficient energy to 180 return or crash land safely straight ahead in any form. The power loss happened at the most critical phase of flight. Plus, they were on the heavy side.
When deciding recently whether to use CHECK ('a', 'b', 'c') vs ENUM, I believe a search/LLM-query stated that it was easier to change a CHECK's values later and not easy for ENUM, so that's what I went with.
As for a lookup table, truly curious, is it worth the complexity of the foreign reference and join?
Please read source docs instead of relying on LLMs, especially for RDBMS. I’ve found they quite often get something subtly wrong; for example, recommending that the PK be added to a secondary composite index in MySQL - this is entirely unnecessary, because all secondary indices in MySQL implicitly include the PK.
> lookup table worth it
Is not doing it worth the risk of referential integrity violations? How important is your data to you? You can say, “oh, the app will handle that” all you want, but humans are not perfect, but RDBMS is as close as you’re ever going to come to it. I have seen orphaned rows and referential violations at every company I’ve been at that didn’t enforce foreign key constraints.
There is a performance hit at scale to not doing it, also: imagine you have a status column with some ENUM-esque values, like CANCELED, APPROVED, etc. If stored as TEXT or VARCHAR, that’s N+(1-2 bytes) per string. At the hundreds of millions or billions of rows scale, this adds up. Storage is cheap, but memory isn’t, and if you’re wasting it on repeated text strings, that’s a lot fewer rows per page you can fit, and so more disk access is required. JSON objects are the same, since both MySQL and Postgres only shift large blob-type objects off-page after a certain threshold.
What you said does matter at scale. As an alternate perspective, for an initial, smaller app, I could see the CHECK method for e.g. processing/completed providing the same correct value constraints as an ENUM or a lookup table, with more flexibility, speed and less complexity. And can be refactored later if needed.
I legitimately don’t understand why a lookup table is ever seen as adding any meaningful amount of complexity.
SELECT a.foo, b.bar
FROM alpha a
JOIN bravo b ON
a.id = b.alpha_id
The speed hit from an INNER JOIN on indexed columns is negligible, and will be dwarfed by network overhead for most places. As to flexibility, if you need a new value, insert it.
for postgres ENUM should be just as easier to change as CHECK
* for adding, there is no problem you can just add entries to an ENUM
* for removing there is a problem because you can't easily remove entries from an ENUM. its only possible to create a new enum type and then change the column type but that is going to cause problems with big tables. however, now your ENUM solution decays to a CHECK+ENUM solution. so it is not really any worse than a CHECK solution.
also, it is possible to add new CHECK constraints to a big table by marking the constraint as 'NOT VALID'. existing rows will not be checked and only new rows will be checked.
Scientifically analyzing a phenomenon to break down its underlying principles and optimize it is a sign of capability, the one attribute found to be equally cool and good. And can be quite cool in some contexts.
All products can be faked, but I thing that GP means "cannot be faked without being obvious". Obvious fakes are not as much of a problem since Amazon has a pretty good return policy.
In the "cannot be faked" category, you can have:
- products so cheap that making a fake wouldn't make sense. for example an unbranded glass jar won't be faked because anything that looks like a glass jar but isn't a glass jar will be more expensive than a glass jar.
- products too complex and/or too low margin to be worth faking. For example, you will probably never find a fake desktop printer, as even the most simple printers are hard to make and sold at a low margin, maybe even at a loss. However, consumables are (very) high margin and you will find fakes, lots of them.
- products that have effective anti-counterfeiting systems. For example, Nintendo Switch games.
No, that is not correct or at least it has not been. Amazon was said to intermingle the inventory in the warehouses, mixing third party products with those shipped and sold by Amazon. So that gave you zero protection.
I read that they made internal changes to tag shippings properly to reduce the risk of that behaviour, but am not sure it is true or has been effective.
Has this co-mingling of sold by Amazon ever actually been documented at any scale beyond “extremely rare stock/pick” mistake? I am of course aware of the option for manufacturers to enable this for their registered products on FBA - and it may not have been optional at one point in time.
When I researched this a while ago I was unable to come up with much compelling evidence that it was an actual thing. It certainly has not happened to me over thousands of purchases - or anyone I know for that matter. Of course a fake could have been so good none of us could tell, but I do actually attempt to inspect carefully.
I have found counterfeit items from other web stores not on Amazon so it’s not like my detection skills are zero. Third party marketplace of course is different.
Heck, even Costco sent me an unsolicited refund for a counterfeit item they unknowingly sold me - so supply chain issues are bound to happen.
I don’t want to defend Amazon too much here, but this one is almost at urban legend status to me. Likely happened at limited scale some time ago, but it’s strange everyone says it’s endemic but no one IRL I know across probably tens of thousands of purchases has noticed it.
I don't think Amazon has ever outright admitted that they do, but Amazon's own terms give them the right to commingle their inventory with those of third party sellers.
F-4 Storage
We will provide storage services as described in these FBA Service Terms once we confirm receipt of delivery. We will keep electronic records that track inventory of Units by identifying the number of Units stored in any fulfillment center. We will not be required to physically mark or segregate Units from other inventory units (e.g., products with the same Amazon standard identification number) owned by us, our Affiliates or third parties in the applicable fulfillment center(s).
Right, that’s FBA. I’m talking about sold by Amazon. I’m specifically talking about a case where a sold by Amazon item came from co-mingled inventory from a FBA seller.
I also know from direct second party experience (I also personally saw the terms) that at least at a certain level of “brand” you can decline this option with Amazon for your registered product skus/ASIN even for FBA. I don’t know if this is offered to everyone though - I know it went through some sort of “deal reg” process in the one case I saw. I imagine this came through some sort of lawsuit or threats of one for a major brand at some point - but that is speculation on my part.
> I’m specifically talking about a case where a sold by Amazon item came from co-mingled inventory from a FBA seller.
The FBA terms I quoted specifically say that Amazon can co-mingle FBA inventory with their own (if the FBA seller doesn't opt out of "virtual tracking").
> The FBA terms I quoted specifically say that Amazon can co-mingle FBA inventory with their own (if the FBA seller doesn't opt out of "virtual tracking").
The wording in the quote explicitly states that an FBA unit can be substituted by owned by Amazon unit or other FBA units. But the wording is not clear whether SBA (Sold By Amazon) unit can be substituted by an FBA inventory. The terms covering Amazon's "first party inventory" (SBA, a.k.a. Amazon retail) are internal to Amazon and are not shared, AFAIK. But i can be wrong :-)
> The wording in the quote explicitly states that an FBA unit can be substituted by owned by Amazon unit or other FBA units. But the wording is not clear whether SBA (Sold By Amazon) unit can be substituted by an FBA inventory.
It would have to go both ways. If there are 10 FBA and 10 SBA units in the inventory, and Amazon decides to fill an FBA order with an SBA unit for operational reasons, now there are 10 FBA and 9 SBA units in inventory but the FBA seller only owns 9 units. That 10th FBA unit eventually has to go somewhere. The only options are that it fulfills an SBA order or Amazon forces the FBA seller to buy the SBA unit that Amazon shipped for the FBA order. As far as I know the latter does not happen.
But that has to go in both directions, necessarily. If they are not marked, as the terms say, they can't fulfill FBA from SBA but not SBA from FBA. It's all one big pile.
I don't believe this to be true. SBA in theory has it's own "pile" that they can of course use to substitute with a FBA third party seller if they deem it cheaper as they are confident that they are substituting like for like.
Given how FBA items are labeled differently (the Amazon required ASIN sticker) than SBA I can't recall a time I've received a third party item when buying direct from Amazon. I also can't really say with any certainty it does not or did not happen, but it was not obvious at least.
I've also seen contracts the explicitly forbid the co-mingling for brands that sell direct to Amazon. By necessity these would need to be under different piles on the backend - and it's easy to see different ASINs for the same SKU by searching for common big brand items. There will be a SBA listing, and then many other listings gaming the qty/size of the item that are FBA. An item that comes in the same size and packaging often is listed twice (or more) times with one being SBA and the rest third party.
It's definitely clear as mud, but I think the "sold by amazon/fulfilled by amazon" being co-mingled is largely urban legend. It's all speculation like this thread here, and very few verifiable facts when you dig into any of the reporting/social media accounts. I'm 100% sure it happens by mistake and very well may have happened as routine business in the past, but these days I cannot come up with an example that shows this happening on any scale.
I have absolutely bought multiple hard drives that were "shipped & sold by amazon" which turned out to be fake/counterfeit in some way. The serial numbers did not verify on the manufacturer's website either and they were completely DOA.
'We previously described ... as "rate limits", which wasn't an intuitive way to describe the limit. It is a usage credit pool'
Very strange that they decided to describe monthly credits as rate limits, and then spin it as 'unintuitive'. Feels like someone is trying to pull a fast one.
Well, rate limits take a moving window of time (say, one second) and check how many requests you make during that time, and throttle you, if necessary.
You need a high-touch process, something like wash with high heat, maybe disinfectant, not overloaded, separate loads (cross-contamination). Dry with high heat for a long time, run a hot empty cycle after to clean machine.
In an ideal world, the host cares about your health and cleanliness and of course does all this for your sake. In the real world, it's toss and wash for minimal care, time and money.
reply