Love this. An example of complete and total dominion over the machine. Great quote here too lol
> Prometheus stole fire from the gods and gave it to man. For this he was chained to a rock and tortured for eternity.
show comments
catapart
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?
show comments
my_throwaway23
I presume you'll add the network stack next, so that I can use my favourite, most useful packages?
import isOdd from "https://unpkg.com/is-odd";
show comments
eqvinox
> If this makes you grin, you are probably holding the torch.
What if it makes me recoil in horror? screams into the void
redvulps
next step is to create a UEFI TUI using react (please don't)
show comments
bayindirh
This project will go places. Like every silly project not intended for production. :)
javascriptfan69
Beautiful
edward28
Wow, this is cursed.
show comments
GranPC
"The Birth and Death of JavaScript" is coming true after all.
show comments
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.
show comments
pwdisswordfishy
Does it manage to support floats? I am not sure if those can be safely used in the UEFI environment. (I recall GRUB’s build of Lua being integer-only, and Linux avoiding the use of floating-point arithmetic in kernel mode, but I don’t remember the reason.)
show comments
juancn
This is both so impressive and cursed that I'm not sure how to feel.
sanufar
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
show comments
fennec-posix
good. god.
lioeters
Turning in the widening gyre, the falcon cannot hear the falconer. The center cannot hold.. The old prophecy is coming true.
raphaelmolly8
The choice of Duktape here is smart — it's one of the few JS engines that can actually run freestanding with minimal libc stubs, since it was designed for embedding in constrained environments. V8 or SpiderMonkey would be a nightmare to get running pre-boot.
What I find most interesting is the UEFI services binding approach. Rather than trying to abstract away the hardware, it exposes the raw EFI protocols (GraphicsOutput, SimpleFileSystem, etc.) directly to JS. That's a much more pragmatic design than trying to build a full HAL — you get to prototype UEFI applications rapidly while keeping the escape hatch to C for anything performance-critical.
Would love to see if anyone tries hooking this into UEFI's built-in network stack for PXE boot scripting. That could actually be useful beyond the novelty factor.
show comments
Decabytes
I’m always amazed and slightly envious of what programming languages with large developer bases can do. I mean if a language is Turing complete it can do anything, but JavaScript takes this to the extreme.
Mind you I never said anything about quality or performance, obviously doing everything in JavaScript comes with it’s own issues but if you were to say that someone got JavaScript running in the Linux kernel as a POC I wouldn’t even be surprised
vaylian
Could this be used as a learning tool? Rebooting the computer takes so much more time compared to reloading the browser tab. And you probably can't brick your computer.
fbnszb
Yeah, but your [developers] were so preoccupied with whether or not they could, they didn't stop to think if they should.
Smalltalker-80
Can't wait for browser support for this... ;-)
show comments
moffkalast
>boot sector
>looks inside
>node modules
smetannik
Cursed, but fun
IshKebab
Javascript is a horrible choice but I think having a scripting language for this is actually quite a good idea. If only there was a popular scripting language that didn't totally suck balls.
rafram
This is incredible.
ycombinatornews
> If this makes you grin you are probably holding a torch
Hilarious
g051051
"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should."
Pretty neat, though.
bwat49
Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should!
Oh hey, we've reached the "Metal" stage! https://www.destroyallsoftware.com/talks/the-birth-and-death...
Love this. An example of complete and total dominion over the machine. Great quote here too lol
> Prometheus stole fire from the gods and gave it to man. For this he was chained to a rock and tortured for eternity.
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 presume you'll add the network stack next, so that I can use my favourite, most useful packages?
> If this makes you grin, you are probably holding the torch.
What if it makes me recoil in horror? screams into the void
next step is to create a UEFI TUI using react (please don't)
This project will go places. Like every silly project not intended for production. :)
Beautiful
Wow, this is cursed.
"The Birth and Death of JavaScript" is coming true after all.
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.
Does it manage to support floats? I am not sure if those can be safely used in the UEFI environment. (I recall GRUB’s build of Lua being integer-only, and Linux avoiding the use of floating-point arithmetic in kernel mode, but I don’t remember the reason.)
This is both so impressive and cursed that I'm not sure how to feel.
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
good. god.
Turning in the widening gyre, the falcon cannot hear the falconer. The center cannot hold.. The old prophecy is coming true.
The choice of Duktape here is smart — it's one of the few JS engines that can actually run freestanding with minimal libc stubs, since it was designed for embedding in constrained environments. V8 or SpiderMonkey would be a nightmare to get running pre-boot.
What I find most interesting is the UEFI services binding approach. Rather than trying to abstract away the hardware, it exposes the raw EFI protocols (GraphicsOutput, SimpleFileSystem, etc.) directly to JS. That's a much more pragmatic design than trying to build a full HAL — you get to prototype UEFI applications rapidly while keeping the escape hatch to C for anything performance-critical.
Would love to see if anyone tries hooking this into UEFI's built-in network stack for PXE boot scripting. That could actually be useful beyond the novelty factor.
I’m always amazed and slightly envious of what programming languages with large developer bases can do. I mean if a language is Turing complete it can do anything, but JavaScript takes this to the extreme.
Mind you I never said anything about quality or performance, obviously doing everything in JavaScript comes with it’s own issues but if you were to say that someone got JavaScript running in the Linux kernel as a POC I wouldn’t even be surprised
Could this be used as a learning tool? Rebooting the computer takes so much more time compared to reloading the browser tab. And you probably can't brick your computer.
Yeah, but your [developers] were so preoccupied with whether or not they could, they didn't stop to think if they should.
Can't wait for browser support for this... ;-)
>boot sector
>looks inside
>node modules
Cursed, but fun
Javascript is a horrible choice but I think having a scripting language for this is actually quite a good idea. If only there was a popular scripting language that didn't totally suck balls.
This is incredible.
> If this makes you grin you are probably holding a torch
Hilarious
"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should."
Pretty neat, though.
Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should!
Awesome! Everything will be rewritten in JS
It begins!
Finally!
I love it.
But why?
Cursed