Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UEFI Bindings for JavaScript

codeberg.org

Post reply on HN
Print view View original

61–70 of 117 posts

Re: UEFI Bindings for JavaScript

#61

Post by hajile »

catapart wrote: post #15

Can someone break this down for me? Looks like it's using... C? to load a js interpreter which bootstraps an API around all UEFI features? Do I have that right? And, if so, does that mean that once the API has been bootstrapped, one could actually write an OS in js? Or are there other abstractions that would need to be migrated first?

I'm pretty sure someone already compiled Linux to asm.js a few years ago. As asm.js is/was a subset of JS, you could say it's already been done. In theory, you could continue work from there in JS.

https://medium.com/@retrage/lkl-js-running-linux-kernel-on-j...

Re: UEFI Bindings for JavaScript

#63

Post by cluckindan »

fnimick wrote: post #56
sanufar wrote: post #54

This is hilarious lol, it’ll be any day now before we get a full JS kernel. Garbage collection could be an obstacle, but I know there have been some kernels written in Go/Java before

Who needs to garbage collect? Just leak memory until the system dies! That strategy seems to be good enough for claude code, anyway.

If it’s good enough for missile guidance systems, it’s good enough for me.

Re: UEFI Bindings for JavaScript

#64

Post by shevy-java »

I think there are two philosophies here:

1) JavaScript must stay in the box (aka in the browser).

2) JavaScript as a general purpose programming language.

While I can absolutely understand 1), I have had wanted to access the filesystem via JavaScript, just as I do via ruby or python, for local use only. After I googled for a while, they would say that this is not possible unless one uses npm/node. I think this shows that there are use cases here and the "default" JavaScript, aka 1), does not cover these. I do not like JavaScript, but based on my own use cases, I actually favour 2) far more than 1). So from that point of view, being able to access UEFI can also be useful. So why not.

Re: UEFI Bindings for JavaScript

#65

Post by Zambyte »

tatskaari wrote: post #59
catapart wrote: post #15

Can someone break this down for me? Looks like it's using... C? to load a js interpreter which bootstraps an API around all UEFI features? Do I have that right? And, if so, does that mean that once the API has been bootstrapped, one could actually write an OS in js? Or are there other abstractions that would need to be migrated first?

You don't need a JS bootloader to write an OS in JS. The bootloader just drops the machine into some memory address for it to start executing your OS init script. that bit could be a Javascript interpreter. You can't do much with the architecture in Javascript though, because it doesn't allow you to map memory directly to your types (unless there's some ungodly nonesense I'm not aware of) so you'll have to drop into…

An OS doesn't need to have a user space :)

Re: UEFI Bindings for JavaScript

#68

Post by notpushkin »

shevy-java wrote: post #64

I think there are two philosophies here: 1) JavaScript must stay in the box (aka in the browser). 2) JavaScript as a general purpose programming language. While I can absolutely understand 1), I have had wanted to access the filesystem via JavaScript, just as I do via ruby or python, for local use only. After I googled for a while, they would say that this is not possible unless one uses npm/node. I think this shows…

> I have had wanted to access the filesystem via JavaScript, just as I do via ruby or python

There are some (limited) ways to do so now: https://developer.mozilla.org/en-US/docs/Web/API/File_System...

As for (1) vs (2), it’s not really an issue of JavaScript at all. The main question is, do you want to build something that runs in a browser? If you’re building a web app, you’ll have to use the sandboxed APIs (and probably JavaScript). If you don’t care about the runtime, yeah, you can use Node or Bun or Deno (or use another language altogether).

Re: UEFI Bindings for JavaScript

#69

Post by DJBunnies »

shevy-java wrote: post #64

I think there are two philosophies here: 1) JavaScript must stay in the box (aka in the browser). 2) JavaScript as a general purpose programming language. While I can absolutely understand 1), I have had wanted to access the filesystem via JavaScript, just as I do via ruby or python, for local use only. After I googled for a while, they would say that this is not possible unless one uses npm/node. I think this shows…

Try webkitdirectory file attribute for browser access to the file system.

Re: UEFI Bindings for JavaScript

#70

Post by epistasis »

fnimick wrote: post #47

Oh hey, we've reached the "Metal" stage! https://www.destroyallsoftware.com/talks/the-birth-and-death...

Whoa, I haven not been following ASM.js stuff in any detail.

Seeing that Metal replaces kernel/userspace boundaries with VM protections for memory, meaning that system call overhead is eliminated, at the price of ASM/VM overhead.

What a fascinating idea. Kidding on the square...

Post reply on HN