While we’re applauding brevity, three cheers for the first line being “model context protocol”. While yes, this one is common, it’s still nice not having to scroll through 20 screens of blah to still not find out what the thing is.
Calling it ‘next-token prediction’ is missing the forest for the trees. The reason prediction gives rise to so many capabilities is that to effectively predict something requires modelling the entities involved and their capabilities. You can’t predict a cat’s next action without knowing how to chase a mouse.
Anything important should be virtualised and regularly snapshotted. Nothing is invulnerable but if it can be reconstituted in an hour, that’s close enough. If it isn’t and you care enough then a standby server with failover should take care of it.
Embedded software is definitely more “real” coding than industrial, but that’s partly because we don’t get as much excuse to dig into it at the industrial level.
Everyone I’ve met in this role has taken a different path to get here. Some are software engineers (like me), IT or networking techs who got into automation and learned more about electronic, electrical and mechanical hardware in the process. Some are electricians or comms techs or hydraulic fitters or mechanical engineers who learned to program PLCs.
I don’t miss gear changes and clutch control any more than I miss a manual choke or tuning carburettors. They were fun in a way but they were intermediate goals between me and going fast. EVs skip straight to the fast.
We spent so much time talking about the dangers of AI ‘escaping’ when what actually happened is we gave it a scope of work and an internet connection and demanded it get to work.
There’s a difference between cultivating failure and cultivating willingness to fail in the pursuit of success. Many people are too scared of failing (or of being perceived to have failed) to actually try anything that’s not 100% safe.
It’s hard to break in to, but industrial automation can be incredibly satisfying. The code itself is quite simple compared to ‘real’ software engineering, but you’re solving actual real physical problems in the real world, with tangible (and often lucrative) physical results. It’s extremely cross-disciplinary so if you like getting on the tools that’s always an option, it’s like the ultimate ‘full stack’ development role.
I don’t think we’re far off a “final” video codec, in the sense that jpg and mp3 and zip are effectively “final” image and sound and data codecs. Sure, there are newer codecs with higher compression foot a given quality level, but at some point it’s good enough to not bother upgrading, especially when the new version costs exponentially more for negligible gain.
…maybe THIS one will be The Final Codec… doodoodoo dooo
> this is how much his companies are estimated to have
Not even ‘to have’, just ‘to be worth, if all of their shares could be sold at the price of the recent ones’. It’s a number only loosely (albeit obviously positively) correlated with actual spending power.
Have you re-read it recently? Some of those books were fun to read but not really something to use as a field manual. Then again some of them were great! I had a book that started with explaining how a battery and a light globe worked, went through how to make a DC motor out of copper wire and a cork, and ended with a crystal radio and I think a radio homing beacon (the latter might have been in another book.)
Either it depends a lot on the model, or I’m bad at chat, or both, because in my experience once a chat starts going off the rails it’s pretty hard to correct the initial misconception. I find it works better to backtrack to just before the misconception and edit my previous response to head it off at the pass.