The history here, as I understand it, was that they imagined you would use custom elements from multiple third parties, so any shared CSS definitions would cause breakages.
There’s a specific downside to LLM-based development that people can get neck deep in a new project without interfacing with the existing work in the field.
In this case, this is basically a poorly specified implementation of half of XMPP. Of course, I half expect the LLM would have mentioned that at some point, but the repository does not.
Unfortunately XMPP is an absolutely terrible protocol. IRC's not much good either, but at least it has the excuse of being ancient and limited in what it wanted to achieve.
I don't know how it just happens that sending text messages to people can manage to result in specs that are painful to implement.
IRC is good in that it is open, durable, and slow moving. All of those points are intentional features that make it a stable cockroach in a nuclear world.
I briefly entertained building a modern chat experience on top of IRC when I came to this realization.
IRC really is good. It's reliable too, but it really fell behind the times and never pushed forward with additions to the spec and such. When the clients and libraries tapered off too it just felt like it froze.
>Unfortunately XMPP is an absolutely terrible protocol
Can you provide more details here? I've never seen an issue with the protocol at all, more issues with feature difference between servers depending on what they have decided to implement or not.
Most times I've seen complaints about it, it boils down to "XML being yucky" and the extension component model being difficult to write clients for, which is true but not really a fault of the protocol, it's more of an inherent tradeoff of supporting opt-in extensions at all
I don't have that many problems with XML myself, but XMPP is weird even in XML land, because it tries to do XML all the way.
For instance, it works as a constant, uninterrupted stream. You never close the document until the disconnection. Which means you absolutely have to parse it with a stream parser.
It could have been something sensible, like a document per message: "Here's 300 characters of XML document: <xml>....". But nope.
What’s so complex about it? From what I gather (after skimming the document just now), you attach an extra element to a message which says how to style which parts of the message, from codepoint n to codepoint m, essentially. At least conceptually, that seems really simple and straightforward.
Are there more elegant or natural ways to do it? Probably. But when you say ‘extremely complex’, saying ‘codepoints 7 to 15 should be bold’ is not what comes to my mind.
* It's not standard. You can't plug in some normal formatting library there and be done with it.
* You'll probably end up having to write conversions back and forth.
* It's fragile -- if anything gets misaligned it'll break
* It's tooling unfriendly. Think things like Nagios, Grafana, etc sending formatted notifications. Everything can do this or <b>this</b>, but practically nothing is set up to accommodate this format.
* It leaks into other subsystems. You can't eg, just search/replace/insert/delete words if you need to for any reason without breaking this.
Is it the worst thing ever? No, but it seems to go with the pattern that nothing in XMPP is normal or comfortable. Everything has this weird particular flavor to it and more complexity than necessary.
If it were up to me, my option would be to support 2 things: Markdown for simple cases, and embedded HTML for when you really have to get fancy. Each of those can be handed out to existing code and you don't ever have to keep adding extensions because what if people want colors or something now.
None of this seems particularly different from doing <i>spans</i> inline (what if you forget to close one? or they overlap?), but it has a major benefit of being very backwards compatible, supporting future variants in parallel for gradual migration, and doesn't require any changes to search tools. And separating markup instructions from content is generally a very good idea.
And you could use markdown. Just get the rendered spanned text result and transpile it. This would be true for any editor as well, just get convert it to spanned text, edit, convert back.
And with HTML you'll still have to specify what subset you support, and many tools won't support that either. Markdown suffers from this too, by supporting embedded HTML, though at least commonmark is pretty baseline and well supported.
AFAIK, it's Matrix markup, the idea is to make plaintext easy to extract, so you can send plaintext notifications, keep it simple. Markdown is fragile too for some reason. You can't use normal libraries with untrusted messages, because normal libraries work only with trusted data. HTML sanitization works like conversion between different formats.
Since the whole thing takes place in XML land I think there's no excuse for making clients implement markdown parsers as well. Bold should be <b> or <bold> or at least <font style="bold"> or <span style="font-weight:bold">. Embedding markdown in XML is silly.
There is zero baggage on NOSTR regarding identities. An npub became the non-ambiguous way to reference anyone regardless of where they are writing from.
Thank you for the reference to that project called anproto, never had heard of it and I'm still without understanding what problem it really solves. Seems to encrypt texts but then contains zero outside metadata to route it somewhere. The website is very scarce on details for someone unfamiliar the scuttle-something they mention.
The nostr baggage I referred to is the crypto culture on the network. I appreciate nostr for being sparse as well. ActivityPub doesn't feel approachable re: understanding the protocol.
There's an example ANproto in use at https://wiredove.net it's pretty clean but not very active, yet another experimental social network playground!
NOSTR notes are very flexible. For example you can have the json include metadata which is essential to know where it should be going, or you can encrypt everything and send what looks like "garbage" to an open relay that can only be fetched by anyone with a key.
There are dedicated profile notes which define which relays that account/identity prefers to send their messages but everything is flexible. It does forego much of the routing metadata, which in my opinion is an obstacle when you don't know which stations/relays are placed on a given geography but you want the message to "navigate" (sometimes quite literally) to a place/region.
For that type of things I'm a biased fan of https://xprs.dev because it bridges NOSTR identities/signing/encryption with APRS that can use store/forward and the routing follows any possible method include USB drives.
* It's hard to even parse, XMPP uses an uninterrupted XML stream.
* The contents are often baroque and complex
* Standards are a mess, and stuff that should be in core isn't
* Data loss is possible
* Protocol wasn't made for mobile devices
* Multiple devices are terribly supported
* Data loss is possible
From my attempts long ago, and other testimonials, writing an XMPP client is a full time job of solving weird problems that shouldn't exist in something better designed.
> We hear this too often: “XMPP uses XML. It should use JSON—it’s more modern.”
I can't take this write-up seriously if it starts like that. I still read the whole thing though and I couldn't find any solid argument as to why someone would prefer XML to JSON for XMPP.
> This is especially true in browser environments, where XMPP streams run over WebSockets, which naturally frames the XMPP protocol. That’s why you are never actually working with XML trees consuming large chunks of memory. Modern implementations like XMPP.js go further and use LTX—a lightweight parser built specifically for XMPP’s streaming model—rather than the browser’s DOM parser. The result: developers work with JSON-like objects anyway. The wire format becomes invisible to your application code.
That to me, is an argument for using JSON, not XML. XML is strong when you have elements referencing other elements in your document structure or DOCTYPE for grammar defs. I might be missing something but I don't get how streaming XML is to be preferred over JSON for XMPP.
If it was actually using XML as a markup language then that would be a reason to stick with it. But XML seems to be complicating things much more than it simplifies.
>> XML remains the best format for representing trees—deep hierarchies of nested data. JSON handles flatter structures well, but good messaging protocols are extensible: extensions can be embedded at different levels and composed together, like Lego bricks. That’s where XML shines.
Anything reasonable you'd be doing with messaging protocol is pretty flat.
It should be JSON with embedded XML for message text markup, playing to each ones strengths... not combining two sets of weaknesses by framing in XML and then using Markdown to format the messages.
I will say that the middle layer is not great. I have an XMPP bot and the "interaction with the network" stuff really is ugly and unfun.
I think the protocol itself is... I mean it's fine, I guess? Protocols are tricky because a lot of stuff is bolted on and it's not really super stateless as a protocol. But like all the Python XMPP client libs (for example) are all real janky.
The protocol is complex enough to where the "simple and easy" client libs require way more up front design.
I once implemented the presence and basic messaging functionality of XMPP for a web site, using a braindead bridge (that I also wrote; so, the meaningful logic lived in the browser).
Considering I'd never hosted an XMPP daemon and didn't know anything about the protocol (I'd used XMPP clients a little bit, but had never looked at the protocol) and got a server (that part, I didn't write), an auth connector for our website's authentication system (so the daemon would authenticate against that instead), prod-ready and the features I wanted all working smoothly and reliably in maybe three weeks of very part-time work (this'd be, like, 3-4 part-time days with LLMs now, tops, from the same starting point)... seems decent to me? I mean I did direct work with the protocol, didn't just glue together libraries, and it was pretty damn good. Also (and I know browsers seem to be retreating on this front, which sucks) being XML made it very nice to work with in a Web context, since you can just ask the browser to turn ~any XML into a DOM for you, and get a bunch of functionality for free.
> I don't know how it just happens that sending text messages to people can manage to result in specs that are painful to implement.
This is what boggles my mind. We're talking: Text. Over the Internet. It should not be a complex, difficult problem! We've been sending text over the Internet from the moment the Internet went online. So how is it that 10 companies have managed to find 30 different ways to do it, which are all incompatible with each other? You have to TRY to fail this badly.
This is what boggles my mind. We're talking decades of arguments and discussions, dozens of different ways to do it, with dozens of tradeoffs that you could start listing with 20 seconds of thought, and still people just pop in like "why isn't it simple??" as if that's some award winning insight.
Come on, try! Start listing some of the core features of the different protocols/clients and answer your own question as to why it isn't simple! Presence. Chat history while offline. Threading. Mobile devices. Intermittent/mobile/cellular/wifi/CGNAT connectivity. Multiple clients on the same identity and presence. Identity establishing and confirming. Encryption. End-to-end encryption. Backing up and restoring chats, encrypted chats, group chats. Federation. Friends/groups/permissions/trust boundaries. Markup, markdown, formatting, images, emoji, unicode, code blocks. Audio, video, broadcast, multicast. Discovery. Extensibility. Federation. Store-and-forward.
> "We've been sending text over the Internet from the moment the Internet went online"
And IRC has RFC 1459, RFC 2810, RFC 2811, RFC 2812, RFC 2813, RFC 7194 and it does almost none of those things.
And you can still use IRC. But IRC is not good. At this point it's either wilfull ignorance of what people use computers for, or it's indistinguishable from deliberate trolling.
Threading? God, I hate threads in a live chat. Is it never not awkward to use? Slack is the example I'm thinking of, though I'm sure it's shit everywhere else too. In Slack, rather than display the one threaded reply just below (maybe indented), it makes me go to another window, but then someone else is replying non-threaded, so I have to bounce back and forth for the next 10 minutes.
I completely agree. Threads in Slack should be a great way to make conversations easy to navigate but damn did they fsck up ever part of the UX:
- opening threads in a new window is in some hard to find and hard to remember location
- threads can’t be inlined (like you’ve described). I actually like how they’re in a pane to the right but sometimes that causes issues (as you’ve described). Sometimes it’s just that the view is too narrow.
- there’s no way to shift non-threaded comments into the thread. I’ve lost count of the number of times conversations have happened over multiple threads and/or non-threaded replies.
The way they implemented it is a complete clusterfuck.
As an anecdotal counter-point, I love threads in a live chat. When used correctly, it means when my idiot friends start having a heated discussion about some random topic while I'm at work, I get one 'ding' from my phone and then never again until I start interacting or they @ me. As opposed to the 427 new notifications I get on my phone about whether Golden Eye was better than Mario Kart 64.
Ultimately the tech is only as good as the humans that use it. If you're chatting with folks that can't understand the difference between a thread or not, that's a meat-bag issue and not anything an RFC can fix.
I have half-wondered many times whether it would be possible/practical to build a chat system on top of MQTT or similar. Chat seems like mostly a pub/sub problem from where I sit.
That is currently still the differentiator between people producing code and shipping something and people who care and actually have years of experience shipping. At the current state how well you steer the LLM and which questions you ask still matters, maybe in the future "build me an app" will give amazing results, but right now you still need to know what you are doing.
In this case, it's just a waste of tokens as something not very unique was generated that doesn't have a real use case, or solves anyone's problem. As with many AI generated projects, I'm willing to bet that OP themselves will not using it any more in a month.
You guys are way too critical and about the wrong things. "Waste of tokens"? Perhaps the author know of the tradeoffs and just wanted to build something.
How you went from seeing somebody's post to deciding they don't care is a pretty big jump, one that isn't warranted. This kind of post seems like the old but now more elaborated form of hating on something that you don't even know what it is.
It just isn't fair to the work that has been put in.
I agree. This is one thing that's gotten me about the new wave of poo-pooing projects made since coding agents have gotten big. Five years ago it was 'just build something!'. I understand the market is more saturated now so building something isn't as valuable as it used to be, but it still shouldn't be treated as a negative. I don't know anything about the creator's background, but even if this project is ultimately redundant and unnecessary, it's still pretty cool that they built something.
or maybe they know about XMPP and prefer IRC. I have always wanted to build one of these on top of IRC. I grew up on IRC and sometimes just the nostalgia of familiar tech is what drives us to build towards it not how good it is.
I've done this a few times. If I had to gesture at the root cause I'd say: LLMs lack curiosity and are trained to complete assignments, not to question their validity, so both the research phase and the questioning of intent tend to get short shrift prior to building anything.
I'm not sure I agree. Seems to me to depend a lot on how one interacts with an LLM.
If you tell it to "build me an application X to do Y using programming language Z", it will comply.
If you interactively ask "I need X, can you suggest some options? use an existing product ? or build something using a library ? or build entirely myself ? can you suggest alternatives with pro's and con's ? Anything I should think of before deciding ?" then you will get an entirely different answer.
Maybe we need additional modes, aside from thinking mode, agentic mode etc. we need e.g. "sparring mode" ? or does such a thing already exist ?
Agreed, you have to ask them to look for prior work. But then they will do a good job finding it in most cases. I think it’s partly their universal tunnel vision and partly sycophancy.
> I half expect the LLM would have mentioned that at some point, but the repository does not.
The repository does not even mention this software is LLM-generated.
I wonder when/if the collective realization will land that LLM's failure to retain provenance during training means the code it generates exists in an indeterminate state of public domain / IP trap.
But it's not just for their own purposes. They shared it with the public which means they will get feedback, good and bad. No one forced them to post to HN.
Ya, ive stopped interacting with all new projects, the amount of slop written by people who have no business remotely putting something out there for others to use is untenable.
Matrix turns every chatroom into a blockchain with a distributed consensus algorithm.
IRC (real IRC) solves this by not solving it, and accepting that message order can differ between servers. If two operators kick each other on two different servers at the same time, usually both get kicked - the command is validated on the origin server and the rest of the network takes it as gospel, even if it doesn't make much sense in their own local state.
”There’s a specific downside to LLM-based development that people can get neck deep in a new project without interfacing with the existing work in the field.”
That’s because it’s a paradigm shift, not meant to be planned or organized by humans. The prior paradigm was that there were subject-matter experts who were human. The new paradigm is that the only author of all code is to be a machine. This new paradigm requires removing all prior authors (who happen to be human), and removing them simply requires overcrowding their output such that it’s not locatable or trustworthy.
That’s the ideal, but if you have the person at the keyboard doing too much of the planning then it’s really easy for the other person to just check out mentally.
For what it’s worth, the author would not consider this a bug. He does it (as I understand) because he distrusts the research on the impact of line length on readability.
"I easily observe hundreds to thousands of bugs per week"
which should be rewritten as
"I easily observe hundreds to thousands of things that I consider to be bugs per week"
which is to say that the "bug" is in the eye of the beholder. It seems the author stretches the definition of "bug" to include cases where something functions, but in a manner that is open to improvement or not to his taste.
The thing that everyone always misses in these conversations is that screens over buttons is a cost cutting measure, not a first-principles design decision.
It means the UI can be designed and developed mostly independently of the physical controls, which helps reduce rework. I also expect it reduces costs for manufacture and assembly.
I’m in favour of more physical controls, but it surprises me that this rarely comes up. I suppose “people are idiots” is a more appealing explanation.
Somehow, the Dacia Sandero has physical controls for climate control and physical buttons on the steering wheel. It manages to do that whilst being one of the cheapest cars you can buy.
Having fewer functions means fewer controls are required. Fewer controls means fewer buttons. KISS tends to promote this.
If it's the choice between $50 worth of buttons and $100 worth of touchscreen, then $50 worth of buttons wins on cheapness.
And at that end of the market, it works (and it makes sense that it works).
---
But at the other end of the market: Common luxury cars have lots of features, and KISS isn't really one of the design goals (if a customer wanted cheap and simple instead, perhaps they'd be shopping for a Dacia instead). Things are still built down to a cost, but there's a greater quantity of those things.
When the choice is between $200 worth of buttons or $100 worth of touchscreen, then $100 worth of touchscreen wins.
> But at the other end of the market: Common luxury cars have lots of features, and KISS isn't really one of the design goals (if a customer wanted cheap and simple instead, perhaps they'd be shopping for a Dacia instead).
It wasn't always like this. Mercedes-Benz used to make high quality, straightforward automobiles without all the inspector gadget james bond crap. See e.g. W123, W124, W126. Luxury meant high build quality, safety, comfort, easy maintenance, and a lifetime of reliable, dependable performance. Not features--you get the same basic features (ok, temperature regulated climate control is kind of novel for the late '70s-early '80s W123). But this stuff was minimal. Now the whole goddamn car is an iphone app. It's disgusting.
The self-leveling hydraulic suspension in the W123 wagon was also a complication. The climate control system was failure prone, but failed in a sensible way--when the control unit failed it would no longer maintain a set temperature, but would still work as an open-loop system. The cruise control "computer" (completely analog device) was also prone to failure. But the thing is all that stuff was implemented simply, reliably, and with an eye towards service and maintainability. Maintaining the systems on a W123 was easy. I did it for almost a decade. It was a fancy car, but in a sensible high-quality way. It was built to be understood. There were excellent printed, bound shop manuals. It was obvious that an immense amount of thought went into the UX of working on that car. It wasn't just a luxurious car to drive it was also a luxurious car to maintain. Even the fucking hose clamps were special.. like, they had a continuous metal bearing surface so they don't cause pinch points and raised bosses for the worm gear threads to ride on instead of the punched slots you commonly find. Contrast that with the situation today. Everything was a lot better before corporations started using software as a wedge to separate users from real, meaningful ownership of their machines. It didn't have to be like that, they could have done it differently. Software could have been a wonderful thing for the automobile, but the way they chose to do it made it awful instead. And now everything is an iphone app with subscriptions and in-app purchases and engagement metrics. It's disgusting what these people have done to the world.
Now it's reminding me more of the E36 I used to drive.
Dual-zone auto temperature control failed? Heat still works, at least -- the "all the way on" position for the driver's side temperature knob was not a potentiometer, but was instead simple switch that opened the valves. Not perfect, but not complete failure: Good enough to get from A to B without the window fogging or freezing in the cold.
But those manifold, solenoid heater valve assemblies would split open. The valve seats would rot. The former issue was and end-of-the-ride situation; the latter just let them bypass when they shouldn't. That was an expensive assembly.
That era of BMW allowed parts makers to brand their stuff, and the only American-made part I ever found on the car was an HVAC control module -- which, coincidentally, is the only electronics box that ever died on it. ;)
Despite the awesome hose clamps (which I understand to be DIN standard 3017 A -- you might see if those are what you remember from the W123 days), nearly everything about the car was a cooling-related system issue. The upper necks would just break off of the radiators, though they were flawless until that point. The water pump impellers were all initially made with plastic and those all failed (scattering bits to the nether regions), then they switched to metal, and then an improved plastic that seemed better. There were two cooling fans; one two-speed electric, and one crank-driven fan with a clutch -- one for each side of the radiator. The former worked well. The latter tended to eventually explode. It worked OK with only the electric one in-place, though. And the hoses were very good.
I never had a factory shop manual for it, but Bentley book was very good.
Except the instructions in the Bentley book for replacing the cabin air filter (luxury!) were wrong -- they missed a giant, black bolt at the top, center of that inside of that black, dark glove box. Those wrong instructions lead to ~every E36's glove box to eventually sag as people go WTF and start tearing way more things apart than was necessary and tugging on them in ways that they should not be tugged on.
There were more cool parts. The engine bay sure seemed crowded, but it was easy to get around that: The airbox, intake plenum, and MAF came right out, along with the Bowden-connected cruise control motor, with a couple of M8 nuts and a hose clamp from the factory toolkit and one tidy-AF twist-lock electrical connector. That made all kinds of room to get to most of the important stuff and literally took less than a minute with some practice.
Like the idle air control valve. It was under the intake manifold and it needed a drop of oil in the right spot every 5 or 10 years to keep working right, but it wasn't bad to get to at all with that area opened up.
The fuses were plug-in blade fuses that could be replaced inexpensively with a trip to any auto parts store or most 24-hour gas stations, but they were special in their own way: They were visually inspectable. Rather than appearing as a flat stamping of fusible metal that was inscrutable without pulling them out one at a time, there were two legs that supported a length of fusible wire at the top of the overall plastic body. That fusible wire could be plainly seen with the fuses in-situ. (I haven't figured out how to buy this style inexpensively, but I'd sure like to.)
BMW parts tended to be surprisingly inexpensive, and also easy to find. BMW's ETK parts index is an amazing and simple resource, and websites like realoem.com have the important bits online. Being armed with a real part number made it trivial to find exactly the right thing, and since the OE parts tended to be branded it was easy to bypass the dealership and get one from the same manufacturer that made the one that already lasted 20 years.
The grease on the window regulators would eventually turn viscous and sticky and glue-like, which lead them to break. But the part that would break was a little platic widget that was available separately, and only cost about $2.50 from the dealership parts counter. Straighten out the skeleton with some hand tools, spin the wheel on which manner of grease to use this time, snap on the new slidey-widgets and it's back rolling again.
The door cards came off easily and were principally made of a molded wood product that just didn't fail, and this lack of failure was promoted by the plastic vapor barrier being held in-place on the steel door frame with plain ol' butyl rubber so it could be removed and reinstalled over and over again without the adhesive dying, or easily-refreshed if that became necessary.
What else? Oil changes were easy and could be accomplished with factory-supplied tools (if a person could find a pit to work in, or sufficient desperation) -- the drain plug and the wheel bolts use the same size wrench. It required a new crush washer, but unlike my Honda those washers were always included in the box with a new filter. And that oil filter was top, front, and center: Open the hood and there it is, completely unoccluded.
The materials and coatings for the metals were good. Mine eventually started showing some body rust, but I drove it all winter, every winter, through the salt brine-soaked roads of northern Ohio. But the important stuff underneath -- like the stuff relating to the fuel filter and brake lines and exhaust -- simply didn't rot.
They're lovely cars to work on, which is good because there was plenty to work on as time ticked on.
I got nearly 300k miles out of mine, which is pretty good for a car that was designed with clay models instead of CAD. :)
Nice! DIN 3017A are the ones! They had a little Benz star stamped on each one. The E36 is another one of those legendary chassis where they basically just got it right. I've looked at a few of them over the years but they were all so beat up that I couldn't justify buying. Some day when it finally rots out or the transmission shreds itself or something I will throw the OM606 from my W210 into a better car.. a mechanically governed OM606 swapped E36 would be super cool if it could be made to fit. I'm sure somebody has done it before. OTOH I also have a super beat up NV4500 collecting dust so I could build something cool with that... for now better to just run it.
I still have the E36. One of these days when I have time and money (hah) I'll see if there's anything left underneath ("it was fine when parked!"), and go about putting different spinny-bits into it.
I'm in a part of the States where German cars are unusual and I never got a taste for diesel, so that tends to lean towards something like a Chevy LS1 and some manner of appropriate manual gearbox as being KISS.
It's a common-enough swap that the questions have all been answered for quite a long time now, and the iron block LS motors aren't too dissimilar in weight from the BMW straight-6 despite having >twice the displacement. That should help keep the handling proper without getting too nuts.
The joy of the OM606 is mostly that it's too simple to fail, isn't it? I think that'd be worth getting into for someone who knows how they tick (but that person isn't me).
And yeah, hose clamps. The BMW ones had little BMW roundels on them, and the dumb ones we use domestically are apparently built to some UPC standard. One is clearly better than the other, but both are superior to whatever Freightliner put on this dude's truck: https://www.youtube.com/watch?v=XfVqr0EkLXA& [language]
An OM606 is just a very stout engine. It's a 6cyl inline 3.0L indirect injected diesel building in some respects on the tradition of its predecessors the OM61x and OM603. It has a basically indestructible bottom end, an efficient 24 valve DOHC head, an inline Bosch M-type injection pump, and it can be pretty easily and inexpensively made to reliably put out enormous HP and torque that melts tires and shreds drivetrains. People call it the "diesel 2JZ" because it'll rev like mad. In stock form it's no slouch but when you put the fuel and air to it (and some stiffer exhaust valve springs to combat valve float) it turns into an absolute fire breathing monster. But a pretty reliable one. It's also a fairly light engine as far as diesels go, comparable to an LS1, various BMW 6cyl engines, Benz M104, etc. Being indirect injected it's not as efficient as a direct injection engine, but a lot more forgiving from a tuning and fuel quality standpoint. Unlike DI engines, IDI engines require no modifications to injection nozzles even when pushing vastly more fuel.
Another thing is that converting one from a computer controlled engine to a fully mechanical engine is very simple. You just remove the Bosch EDC pump and install a mechanical pump from an OM603. The only major difference is in the governor. The EDC pump is "Electronic Diesel Control" or something to that effect--it has an electrically controlled actuator and an ECU and the mechanical pump has a flyweight governor like all the other mechanical pumps, steam locomotives, etc. That makes it attractive for swapping into older vehicles, you can do a brain transplant and turn it into a simple 1 wire engine in like an hour.
The problems with a heavily boosted high output OM606 (or any other diesel) aren't power or torque--you'll get a ton. It's making that power and torque in a way you can actually use, and that won't make obnoxious clouds of black smoke. Stock it makes something like 175hp/240ft*lb, which isn't bad at all. That can be pushed to a bit over 200hp on stock pump internals, or as high as you want (600hp+) with a purpose-built injection pump with larger pumping elements. But you have to feed it enough air to keep exhaust temperatures and smoke under control and that's the problem--big turbo means no boost until high RPM which is fairly limiting from the standpoint of like actually doing car stuff.
Personally, I don't really care about making huge amounts of top end power, I'd rather have a driveable engine. Stock power and torque output--or at least that which is reliably achievable with a stock pump and maybe an HX30 to flow a little more air more efficiently--is plenty. The thing that rocks about the OM606 is it'll go like that for 500k miles with (probably) just routine oil changes. And you'll get like 28-32+mpg the whole time (depending ofc on what you swap it into).
So all that is to say it's kind of the pinnacle of a particular stage of automotive diesel technology--I think it might be the "most modern" IDI diesel ever made. It's too bad the car they surrounded it with is such a pile of hot garbage.
I bet an LS1 E36 would be sick too.
EDIT: lmao just watched the Freightliner video. The one thing on an OM606 that is remotely like that is the overcomplicated fuel tubing on EDC-pumped engines. It has these dogshit plastic push connectors with orings, and some crazy convoluted fuel plumbing through a shutoff valve which basically doesn't do anything useful. The shutoff valve and each end of like a half dozen of these little plastic fuel tubes has o-rings in it which eventually fail and leak fuel everywhere. It's a bit ridiculously overengineered and solves a problem that isn't a big deal--normally to shut off a diesel you just pull the rack all the way back on the injection pump and wait for it to die. For some reason, on the EDC pumps when it does this the RPMs increase for a little bit before it dies. That's what this other electronic solenoid valve solves--by pinching off the fuel upstream of the IP at the same time as pulling the rack back this little RPM blip doesn't happen. But it comes at a terrible plumbing cost. Happily if you use Viton o-rings you only need to change them every 20 years or so. My car is currently disassembled because I'm doing that now :D. This whole system can be deleted if you don't care about the RPMs increasing a little bit when you shut the engine off, or if you do a mechanical brain transplant.
EDIT AGAIN: Ah, one more thing! I forgot about the glow plugs. So.. it's an aluminum head engine, with steel pencil-style glow-plugs screwed into it. These surface inside each precombustion chamber where they glow red hot during the start cycle. This helps atomize the fuel in the cold engine and makes it go brr. Once the engine has been running for a few seconds they shut off, because there's enough residual heat in the prechambers to atomize the fuel. Anyway, because you have steel parts threaded into aluminum parts in the presence of salt and road grime and who knows what on the outside of the head--not to mention the heat and carbon buildup on the inside--this is a recipe for a sticky situation. The torque spec for these things is I believe 27N*m which is not a lot and if you torque them anywhere past 40N*m they're very likely to snap. When one of these little fuckers breaks off in the head it's a very, very bad day. If you're exceptionally lucky it's just an entire day or more of uncomfortable contortions with an angle drill, some tapping, some helicoils, some loctite. But more probably the head is coming off and going to the machine shop. In which case probably you're gonna also want to deck the block.. and at that point why stop there? Best to just do a full rebuild. So, you do not want to break off one of those glowplugs in the head. So... what do you do about that? The answer has a part number: A 001 989 42 51 10. I don't know what this stuff is made out of but I assume it must be incredibly toxic. It's some kind of anti-seize lubricant that is bright white when you put it on the glowplug, and is still bright white when you remove the glowplug a year later. It spent 10000 miles millimeters away from the combustion chamber of a diesel engine and didn't degrade at all. There's also a special reamer tool which also has a part number but I don't have it in front of me. Every year I remove all the glowplugs, clean them, ream and clean the holes, re-apply the anti-seize, and reinstall them. Just to make sure one never gets stuck in the unlikely event I have to replace it.
Cars traditionally have very generic button clusters, like [0]. It is even very common to have dummy buttons in there. Combine that with today's cars where those buttons are hooked up to some MCU to send a CAN message instead of being hardwired to a function-specific cable in a giant loom, and it is suddenly quite easy to change button functionality quite late in the design process for basically zero cost: you just need a slightly different label print and a small firmware patch!
Or, if you want to be 100% flexible, go with the ATM approach where physical buttons are placed next to an icon shown on a screen[1]. All of the flexibility and all of the tactile feedback! You can even go for a multi-level layout, with a top row of mode selection buttons, a bottom row of mode-specific function buttons, and perhaps even a big fat dial with haptic feedback[2]. Or even go all-out Elgato Stream Deck[3].
And sure, the fact that slapping in a giant touchscreen lets them decouple UX design from physical controls is going to play a big role. But it is by far the laziest and least user-friendly way of doing so. If that's the best you can come up with, you probably shouldn't be doing UX design at all.
It's even more in regards to production planning. Building the production pipeline takes long and is inflexible as you need to ensure to pick suppliers which will provide spare parts for a sensible price for the whole lifecycle. Thus you limit capabilities very early in the design cycle.
A software based solution you can finalize last minute and with later updates add extra features. Thus if a competitor provides a feature you don't have to wait years for the next new design, but can deliver based on software development priorities any time, to any series you like (even add after delivery)
The idea that Builder.ai was Indian workers being sold as AI wasn’t true, by the way. That was made up by a crypto influencer on twitter and copied by sloppy news sites. They were a consulting firm that also sold an AI product, with the two clearly separated.
I’m not sure if this is the point you mean to make, but Michio Kanu is one of the bigger cranks in physics communication. He said ion an (maybe the Joe Rigan interview?) that quantum computers would be able to act as a truth detector for AI. He wrote a whole book on quantum computing in fact despite clearly not understanding it at all[0].
See eg the (now removed) HTML imports standard.