I hope there will be a HBR or some other case study done on Yellow, because the interplay between bad loans + union demands + poor management seems like something US businesses need to be more prepared for.
The electrical union that taught me all my fundamental understanding of electrons was created back in the day because the fatality rate among electricians at that time was 1/2 lol.. For every two electricians working to electrify America, one of them wouldn’t make it home to their families.
Ironically, the guy who created the IBEW, Henry Miller, was himself killed on the job after making contact with a live wire and falling off the pole and hitting his head.
In the early days of electricity, the workers had no understanding of the thing they were working with, and they certainly weren’t given proper tools.
The voltage tester of the day was licking the wire to see if it was live. A method thought to save people after electrocution back then was to stick your fingers in their rear to give them a sudden jolt lol.
From the sounds of it, its mostly the bad loans + poor management part that killed Yellow. Management of the company have been asleep at the wheel for some time now, union demands are not likely the precipitating factor here.
EDIT: All I'm pointing out here is that I don't think this can land squarely on union demands, which is what I think some of the press are making it out to be. The actual financial mismanagement of the company precedes anything the union was asking for (which in part, was for Yellow to live up to their previously agreed obligations)
It doesn't seem like the "union demands" killed the company narrative tracks here, since the union demands were things like "You should actually make the contributions to our retirement accounts that you're obligated to make."
The threat of a strike was the final blow, causing them to lose customers and dropped their stock price such that they didn't have anything to borrow with.
All of the bad decisions they'd previously made out them in this position, but the union threatening to strike was the straw that broke their back- despite the union withdrawing the threat.
That last tidbit probably tells you all you need to know about how little chance the company had at surviving.
The company entered into questionable acquisitions though largely to try to become more competitive in the LTL market with their non-unionized competitors. Now they executed the mergers poorly and failed to integrate for too long, but even some of those integration challenges were due to union considerations. So yes management was incompetent but I think being unionized did play a large role in their demise as well.
There’s really only gonna be two camps of developers, working on native apps. Folks at some existing large company, with some sort of Apple partnership to cover cost, or folks working on their side projects to scratch some personal itch. There really isn't gonna be anyone in the middle burning money for a nonexistent user base.
No, you are being misled by “environmental water,” which is a fancy way to say it’s water we don’t use because were not allowed to. This doesn’t make any sense, how can you include water you don’t use in your accounting for water use?
The reason this is there is to downplay the outsized use in agriculture, and also to shift some blame to folks that voted not to allow this water to be used in the first place.
But still, if you want to cut spending and are looking for where your money is spent, you don’t include money you choose not to earn in your list of spending.
One could argue we do already via code generation when we define protobuf definitions or other idl’s. But yeah a chat oriented idl which then code generates c, Go, python, just based on the required problem domain is an interesting vision.
You can do around 100 miles a day on 70% and that’s more than enough for me the way I’m traveling. I have the extended capacity model. It also really depends on the route, with a lot of downhills you can probably get closer to 180 miles on 70%. On a cool night when you can just leave a window open on the trailer (so you don’t need to power it), you can get a full charge and that will get you around 200 miles a day while towing on something that has a decent amount of downhill.
I don't have a lightning but have been thinking about getting one. Thanks for the report.
One thing I thought about is that if I want to go someplace farther than 100 miles, I could just drop the trailer in a parking lot, recharge the truck at a nearby DCFC, then re-hook and be on my way. I've done this on occasion to refuel an ICE tow vehicle at a too-small gas station, and I don't see why it wouldn't work with a lightning.
So is your itinerary to go from KOA to KOA in 100 mile increments? Are there ever times when there isn't a KOA ~100 miles in the direction you want to go?
Yep. This is a quintessential example of “I’m going to learn by recreating the essence of a complex thing”… taken to the end. And then a logo is slapped on top. I’m all for js libs but this is not performant. Just use redis.
no need an extra layer of abstraction to get an "in memory" database in javascript. no need, babel, webpack, ChatGpt, npm and 10000 libraries for this really.
Let me show (works even on the browser):
Run Redis on the same machine. No network latency. You only have a few memcpys and context switches versus an in-process solution, and if those make a difference you shouldn't be using JS anyways
It’s essentially a question of did you take a look the code?
There is comments in the codebase directly where the config values in question are being used. Eg.
Now I’m assuming a base rate of knowledge for this to help, but in general I find diving into the code paths of open source models, usually is a good use of time.
> A human made the decision to widen the guardrails. There aren't a ton of people allowed to do that…
Assuming this is the case, where folks can override during an incident like this, it sounds like the simulation tooling doesn’t have a human loop interface to demonstrate potential effects post override.
Does that type of simulation interface exist in the industry? And would it have helped?
This is the mental leap folks need to be making, the question is when will this type of configurably factual large language model be research benchmarked and productionized.
I have read many similar comments to the grandparent, all saying the same thing, “I tried it, and it turned up wrong facts” all the while they forgot that they were deeply engaged with the content it was producing. Just think of how much our attention is monetized already, money will be poring into this space from here on. It’s only a matter of time.
My argument isn't that I tried it and it didn't work, my argument is that an LLM alone fundamentally cannot work for reliable information retrieval.
Producing hallucinations or not isn't just a setting you can tweak in the model. The entire function of GPT-3 is to guess the next word from the words that came before. It's a hallucination machine that has been trained on so much real-world data and has such a large parameter set that for commonly known and discussed information it does a remarkably good job at creating factual sentences. But as soon as you get out into territory that it doesn't have memorized, it will do the next best thing and produce credible-sounding new material that may or may not be complete nonsense. Again, this isn't a setting you can tune, it's just what a transformer does. It models human language, not all of human cognition.
ChatGPT isn’t trained on next word prediction alone, it was trained on human feedback. The evaluation is next word search, but the model has evolved to give “correct” answers when evaluated that way. So it’s not just the most likely answer anymore.
Also, since we can watch the model evaluation and see all its weights, there’s research that shows you can determine if any answer is a “retrieval” of existing knowledge or a hallucination.
