Yes, this is a separate runtime. Docker handles containerization differently with more overhead. OCI is a 'standard' way of constructing container images and both are compatible with OCI.
Interesting. From the hyundai manual, driver attention monitoring only uses front sensor with no face recognition in the vehicle as far as I can tell. Are you sure your cruise control issue isn’t because of hand sensors?
Also, I think the issue with it stopping the car sounds like ‘collision avoidance forward safety’ which can be disabled according to the manual. I haven’t had any issues so far though.
I also disable lane assist but largely just because I prefer to have full control. The highway driving assist is really neat though.
For those interested or forced to buy a new car — I recently picked up a brand new Hyundai and was impressed the new tech does not get in the way. ‘Driver attention warning’ does not have a face camera, it just uses the front sensor to confirm you’re not all over the place. It can also be disabled. Lane assist can be disabled with one button on the wheel. Almost all important controls are real (non capacitive) buttons. Warnings can be customized. Smart cruise control can be customized. As someone who really liked his 90s Toyota, I’m impressed.
This is something audiences are clearly desperate for today. I think it's obvious when looking at the huge success of Helldivers, Bodycam, Ready Or Not, Arc Raiders, (none of which are particularly innovative) players appreciate high quality, tactile and grounded world interaction.
I've done some basic testing of the CoreAI framework (using Apple's official 'llm-runner' and officially supported .coreai converted models) and seen no noticable performance increase between standard MLX or GGUF with llama.cpp. I'd love to see some thorough benchmarks from someone though.
It was a truly ridiculous idea to put an i9 in any laptop. That generation of i9 is difficult to cool even with liquid cooler systems in big ATX cases.
As much as that’s true it’s clear a huge amount of people have accepted the current state and are working around it, successfully(in terms of ticking an executive’s checkbox) in a lot of cases. And it’s worth considering we’re seeing strong strides outside of model quality in the tooling and integration
While I think the author is entirely right about 'natural language programming' in the current day, if LLMs (or some other AI architecture) continue to improve, it is easy to believe touching code could become unnecessary for even large projects. Consider that this is what software co. executives do all the time: outline a high level goal (software product) to their engineering director, who largely handles the details. We just don't yet know if LLMs will ever manage a level of intelligence and independence in open-ended tasks like this. And, to expand on that, I don't know that intelligence is necessarily the bottleneck for this goal. They can clearly tackle even large engineering tasks, but often complaints are that they miss on important architectural context or choose a suboptimal solution. Maybe with better training, context handling, documentation, these things will cease to be problems.
I think you're misunderstanding the paradigm shift completely -- AI does not just generate code N(x) more quickly. It thinks N(x) faster, it researches N(x) faster, it tests N(x) faster. There are hundreds of tasks that you'll find engineers are offloading to AI every day. The major hurdle right now is actually pivoting LLMs from just generating code: integrating those tasks into workflows. This is why tool-use and agentic workflows have taken engineering by storm.
When someone says passwords are ‘stored’, the assumption will always be ‘stored on disk’. ‘stores in memory’ is not an accurate representation because memory is inherently volatile and they are loaded there temporarily. Plaintext on disk is egregious, plaintext in memory is considerably less so.