Is this written in jest? Because it's very likely where the future of computing is heading. See <a href="https://www.youtube.com/watch?v=kZRE7HIO3vk" rel="nofollow">https://www.youtube.com/watch?v=kZRE7HIO3vk; a lot of people were nagging on Casey because he implied that software was more efficient back when everyone "wrote their own kernel" and how "impossible it would be today". He even mentions how awesome it could be if every game came with it's own bootable USB. Now back then it truly was unthinkable, but today we're edging ever closer to that reality.
For instance, I have a working microkernel written in a Lisp dialect for embedded devices. Compiled to native machine code. 100% LLM generated. ~70k loc. In benchmarks it outperforms most other embedded kernel projects by a significant margin. And it only took around ~$1500 in tokens (API costs all included).
A problem with this approach is that it would put a large burden on the application developer (or development system) to support other devices (or services) than initially planned.
Of course, it would be possible to add new drivers only when necessary, but that would also allow for security problems.
So, in theory it might work, but in practice it would require quite a bit of thought.
Now that we are out of the Cambrian explosion of computing hardware - are drivers such a concern anymore? Is there any chance we start consolidating on a few core interfaces?
I know nothing of hardware, but as far as I know, my keyboard and mouse work everywhere because there is a formal specification on how human interface devices are supposed to operate.
There are probably good (and anti-competitive) reasons for why hardware still needs bespoke drivers, but from the outside, it seems like something we could address. I have no interest in loading your artisanally crafted Wifi driver.
As AI reduces the cost for writing closer to the metal, it's also reducing the cost for creating new metal to target. I suspect we'll see an explosion in new hardware as it's cheaper and easier to design custom solutions.
GPUs, wifi, power/thermal management, firmware. Especially in portable computing there is still a huge amount of hardware support surface area to contend with.
Game consoles worked a lot like this until around the PS3 era, where the disc/cartridge the game came on was shipping binaries for everything including all the hardware support.
This led to some hilarious implementation shenanigans for the Wii as a transitional console, where the Home button pause screen is not in fact a task switch to some underlying console OS but rather a piece of the SDK that is separately-delivered from each individual game.
There are/were approaches around in kernels like includeos, which promised to do as little as possible before hading control to you. So not everybody has to create their own driver's etc, but you get a bootable executable for your application.
Includeos in particular then went towards being a complete "application server" and apparently failed to gain a business as Docker became successful.
Stuff like u images still do that but allow you to bundle your existing software so you don't have to rewrite everything to run on it. The cool thing is that you can freeze at a syscall/hypervisor call like accept. And have very fast response times from cold
When AI proves theorems, it uses divide-and-conquer approach just as humans - it breaks a big theorem into lemmas and tackles lemmas one by one.
An alternative approach where it is just one big-ass logical expression is just not better.
Same thing with code, I think - you need some intermediate results like a calling convention, helper subroutines, etc.
A sufficiently powerful AI can do compilation "mentally" - i.e. producing machine code conforming to a specific calling convention. It can also decompile machine code. But you, obviously, don't gain anything doing it this way, if there's one-to-one correspondence between high-level code and machine code. You might as well just write high-level code.
I really hope that software becomes more efficient. But I don't think that it can only be done by generating machine code directly.
> He even mentions how awesome it could be if every game came with it's own bootable USB. Now back then it truly was unthinkable,
Not only was it thinkable, it was common: <<a href="https://en.wikipedia.org/w/index.php?title=List_of_self-booting_IBM_PC_compatible_games&oldid=1367389021" rel="nofollow">https://en.wikipedia.org/w/index.php?title=List_of_self-boot...>
That is my vision as well, independently of how it turns out to our profession, I see the future being what was previously attempted with 4 GLs, CASE tooling, RUP and co.
However you have something wrong there.
Back then it was the way, we had fully bootable games on floppy disks and tapes that took over the whole computer, and that was also the console programming model for a long time.
comboy · · focus · HN ↗
rfgplk · · focus · HN ↗
For instance, I have a working microkernel written in a Lisp dialect for embedded devices. Compiled to native machine code. 100% LLM generated. ~70k loc. In benchmarks it outperforms most other embedded kernel projects by a significant margin. And it only took around ~$1500 in tokens (API costs all included).
smokel · · focus · HN ↗
Of course, it would be possible to add new drivers only when necessary, but that would also allow for security problems.
So, in theory it might work, but in practice it would require quite a bit of thought.
3eb7988a1663 · · focus · HN ↗
I know nothing of hardware, but as far as I know, my keyboard and mouse work everywhere because there is a formal specification on how human interface devices are supposed to operate.
There are probably good (and anti-competitive) reasons for why hardware still needs bespoke drivers, but from the outside, it seems like something we could address. I have no interest in loading your artisanally crafted Wifi driver.
unsnap_biceps · · focus · HN ↗
PunchyHamster · · focus · HN ↗
For actual real hardware, not really
mikepurvis · · focus · HN ↗
mikepurvis · · focus · HN ↗
This led to some hilarious implementation shenanigans for the Wii as a transitional console, where the Home button pause screen is not in fact a task switch to some underlying console OS but rather a piece of the SDK that is separately-delivered from each individual game.
ref. <a href="https://www.copetti.org/writings/consoles/wii/" rel="nofollow">https://www.copetti.org/writings/consoles/wii/
mejutoco · · focus · HN ↗
johannes1234321 · · focus · HN ↗
Includeos in particular then went towards being a complete "application server" and apparently failed to gain a business as Docker became successful.
<a href="https://includeos.org/" rel="nofollow">https://includeos.org/
alex7o · · focus · HN ↗
pjmlp · · focus · HN ↗
killerstorm · · focus · HN ↗
An alternative approach where it is just one big-ass logical expression is just not better.
Same thing with code, I think - you need some intermediate results like a calling convention, helper subroutines, etc.
A sufficiently powerful AI can do compilation "mentally" - i.e. producing machine code conforming to a specific calling convention. It can also decompile machine code. But you, obviously, don't gain anything doing it this way, if there's one-to-one correspondence between high-level code and machine code. You might as well just write high-level code.
I really hope that software becomes more efficient. But I don't think that it can only be done by generating machine code directly.
teddyh · · focus · HN ↗
Not only was it thinkable, it was common: <<a href="https://en.wikipedia.org/w/index.php?title=List_of_self-booting_IBM_PC_compatible_games&oldid=1367389021" rel="nofollow">https://en.wikipedia.org/w/index.php?title=List_of_self-boot...>
sroerick · · focus · HN ↗
pjmlp · · focus · HN ↗
However you have something wrong there.
Back then it was the way, we had fully bootable games on floppy disks and tapes that took over the whole computer, and that was also the console programming model for a long time.