Saying "This" on a post about "Mimo Code" leads one to, rightly, assume you are referring to "Mimo Code". If they commentor wanted to make a comment about a specific model it would have be clearer to simply mention the model instead of getting there transitively.
The question in my mind is persistence. Everyone goes through the honeymoon phase. I'm absolutely loathing the idea that phones are arriving soon with chatbot junk built deeply into it, enough that the thought is more what if I could maybe just stop using my phone so much. I threw myself at the Llama WhatsApp integration when I first got it, now the idea of having Llama in WhatsApp just feels so dumb.
I was a huge early fan of ChatGPT voice too, but I don't think I've used voice mode anywhere in at least 6 months. The question is what is the right level people are generally going to settle on for the use of these tools in the long term. 80% of my usage isn't much more than a better Google, I could live without it and I could live with cheaper options. I'm not sure the consumer money is going to be there en masse as hoped
Of course it still leaves a huge amount of business cases open, but I suppose the same principle applies. How soon will people tire of talking to robo-voice when they call their bank? etc.
Netlify CTO in 6-18 months: that vibe project that caused me to say writing code is no longer the job got so unmaintainable that I hired a team of 3 to take it over. They're rewriting it by hand because tokens are too expensive now. Nobody could have seen this coming
There are large areas of software where the quality of code is measured by the mental model of its human maintainers. For these areas, LLMs are a net negative because their use degrades the mental model of the human maintainers.
Personally I really think LLMs help radically decrease the bus factor, by making it vastly easier to understand code and systems.
Even just reading the code, their ability to ingest colossal amounts & answer questions in incredibly useful. Once you hook them up to observability, DAP (debug anything protocol), a repl, devtools... their ability to augment and accelerate practitioners is amazing.
There can be a lot of oral history that is lost, for sure, that helps illuminate why things are built the way they are, what the intent was. I've always favored a written culture, that has artifacts that help explain the past. Engineers move projects, move companies: trusting the mental model to live in people's heads has a lot of risk and downsides to it.
The video angle published by the BBC is better, it appears to show one side of the rocket disintegrating and sliding down non-explosively before the large explosion really kicked in. Would hate for this all to be described by a few missing bolts
edit: the failure appears to start at the bottom, this seems to have damaged the structure enough to cause the sliding to start, then the huge fireball seems to begin with a small flash closer to the top of the rocket
What you're seeing is not a 'side' of the rocket sliding down, it's the rocket itself. The other part on the right is the erector stand it was mounted to. Looks like the bottom of the rocket blows out first and begins to collapse. The rocket begins to slide vertically before it all becomes one large fireball. The erector stand didn't survive the explosion either in the end.
That makes a lot more sense, and sibling comment's higher res clip makes it a lot clearer. I knew I was posting a crappy analysis in the hopes someone who understands this stuff would post something more interesting, there is a dearth of technical speculation from googling around
No worries, it's going to be fascinating to hear what the investigation uncovers. Did the sensor data stream send back anything useful in the milliseconds before those sensors ceased to exist? I would assume there were no warning signs or they would have done a stand down on the test itself. So many questions!
Even if you've otherwise put in a lot of effort, presenting it with slop on the home page really sends a bad signal. My eye caught "No proprietary clients. No vendor lock-in." as an AI pattern and I'm immediately drawn to wonder whether the service will still be around even just a few weeks from now.
Thanks for that, My intentions are to stick around for sure. It is genuinely difficult to get a point across in a very short amount of time that people that people will actually recognize. its like doom scrolling where you just get boored of it. Happy to take suggestions.
< is there anything else you would like me to answer or is that good enough - GenericAI answer>
But jokes aside, words are difficult and also not my first language
I don't think any value would be lost in that case by simply deleting the text and not replacing it with anything. AI is particularly bad at inserting this kind of filler, it can sometimes be really hard to spot even though it's right in front of your eyes.
Just more hidden cost of AI.. it's sufficiently hard to avoid these kinds of structural smells that I've gone back to just writing my own copy everywhere.
I think the problem is that half the time the callouts are incorrect (edgelords trying to be clever) or irrelevant (non-native speakers using AI to translate or clarify).
Sustained pushback helps define how the tool is used, and if it only takes a few years of complaints to permanently establish good social norms around it, I think we're better for it. At least, I much prefer this than a world where everyone is too polite to complain about slop until slop is all that is left..
I agree. However, it's gotten so bad that people are calling out AI slop on things they just don't care for — or mistake human writing for AI — which paradoxically becomes its own red flag to ignore the comment, even if there are valid points within.
I just used the em dash twice, and have been doing so for 35 years. This is now supposedly a dead give-away for slop.
Call it slop when it's slop. When it's not total garbage, give it a rest.
5x 400gbit running to a 2U box whoa, the PCI lanes must have heat shielding.
More seriously there is a sensibility limit on extreme density where it's not needed. The idea that you're just going to magically get 2 TBit/s out of those ports seems unlikely even with tweaked software, and you're stuck with a power and comms hotspot that's liable to dictate the remainder of your network design.
At max utilisation that 2U would take 12 hours to drain, and only 12 hours assuming peak and likely unachievable throughput and the box otherwise being completely out of service. Not a great start
Your approach looks interesting but I was curious when you talk about path-based splitting for ART, do you literally mean always on "/"? I know S3 directory buckets always use /, but the classical S3 model had no natural separator character and I was wondering if supporting those styles of prefix or custom delimiter queries suffered any impediment in your approach.
Bookmarked your whole blog for later consumption, interesting stuff!
Thanks for the encouragement! Another author here. Yes, if you are interested you can check our another blog [1] for the internal storage engine. Yes, we are limiting the delimeter to "/", to better support posix FS semantics. I have just finished the fs feature branch which has passed all posix fstests [2].
reply