Why is it a new surface? Either you can run UEFI code, or you can't. Attacking the JS interpreter itself is unrealistic IMHO, it's the poorly written JavaScript running on top of this that might open new surfaces of attack. But other UEFI code is mostly written in C or C++, so let's call that a wash?
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?
Seems like a small number of hobbyists have attempted.
I've heard of people doing this with other high level languages. Basically you need enough low level code to bootstrap a VM. Once you have that, you can make the high level language decide some logic that traditionally would be in C code, like manipulating page tables or whatever.
Automatic Garbage Collection in a kernel probably won't work:
I vaguely remember hearing about someone trying to use .Net in the Windows kernel.
The big problem is garbage collection: If I remember correctly, the fact that "any" operation can fail with an out of memory exception was a huge problem. Another problem was that random pauses for garbage collections in the kernel had major stability issues.
In short, I hope that the js kernel is for amusement and education; otherwise it would need a much more advanced garbage collector then earl 2000's .Net.
> I vaguely remember hearing about someone trying to use .Net in the Windows kernel.
Microsoft did that, it was called Longhorn. That release cycle was long delayed and they abandoned most of its ambitious projects, especially C# in the kernel, and the result was Windows Vista.
GC was not the only reason for the failure of that project. Someone could write a book about it. A lot of it was actually more about the organization of people. I also had heard from insiders that lack of ahead of time compilation was an issue. The other issue I remember hearing about was a complaint that Windows components were not layered cleanly and they ended up with circular dependencies when they tried to rewrite them.
I think it's possible to write a kernel with GC, and to still be judicious about memory usage with a GC language. And I say that as someone who happens to think that a big issue with modern software is that too many programmers are spending their whole education and career to depend on GC without thinking about it carefully. That is to say I'm already a skeptic of high-level languages and GC, but I will still afford that it is technically possible.
My source for that is I was on the Windows team at Microsoft from 2008-2011. I learned a bunch of this history from talking to coworkers who were there. I specifically recall people talking about c# in the kernel.
Another part of it was, IIRC, that Longhorn was based off of the Windows XP core, i.e. the non-server stuff. While the Windows Server development continued apace, with lots of security and hardening to make for a reliable OS to build upon, the Windows Non-Server team continued with the existing mess of a codebase, not prioritizing security features or stability in favor of trying to manage feature creep. Longhorn was meant as a stopgap between XP and 'Blackcomb', but a lot of Blackcomb stuff started creeping backwards, bogging them down.
When security and reliability were suddenly key issues for Microsoft (to the extent that they ever were), it was obvious that what the Longhorn team had built was never going to meet that bar so they started over building off the Windows Server codebase instead.
Most of this story I remember from a video on YouTube of that old guy who worked at Microsoft since forever and left around the time of the Longhorn debacle, but a lot of it is corroborated in the Wikipedia article as well. https://en.wikipedia.org/wiki/Development_of_Windows_Vista
You'd need to write an entire hardware abstraction layer to do anything useful. There's projects that do this for microcontrollers - eg MicroPython and Espruino.
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 C/asm to e.g. interact with the ports/registers/tables to set up userspace.
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.
webuefi has already been shipped by google for use on chromebooks. but mozilla and apple irrationally refuse to implement the standard for "security reasons"
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.)
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.
I don't know if it's only me, but did this guy... Did this guy make a huge mistake?
I think he was trying to bend reality with words. I can see many apps that are running in electron on my laptop, each consuming 300MB+ (e.g. Spotify), while many other apps are written in native Swift for example, especially with the help of AI, giving the best performance possible...
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.
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
I don't have real context here, but I can imagine that a platform where the hardware costs millions of dollars, will be booted up in "Production" exactly once, and is guaranteed to be physically destroyed before it hits 1 day of uptime, just "Give it 128GB of RAM and YOLO (literally)" is great advice!
Note: 128GB of DRAM may add another million dollars to the build cost by 2027 at the current derivative of the $/GB curve
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.
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).
I've been using Deno a LOT for general shell scripting... it's been pretty nice in general. FWIW, Node, Bun and Deno have FS interfaces in the box, so yes, you can do it without npm modules. Though Deno allows you to directly reference the modules/repos from the script without needing a separate install step, package.json or node_modules directory.
It's also a single, self-updating executable and includes a lot in the box. Including SQLite3.
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.
Pretty dang common. OS X and macOS (and maybe iOS and iPadOS, though I'm not certain) have been autocorrecting "--" into "—" for over a decade. Windows users have been using Alt codes for them since approximately forever ago: https://superuser.com/q/811318.
Typography nerds, which are likely overrepresented on HN, love both em dash and en dash, and we especially love knowing when to use each. Punctation geeks, too! If you know what an octothorp or an interrobang are, you've probably been using em dashes for a long time.
Folks who didn't know what an em dash was by name are now experiencing the Baader-Meinhof phenomenon en masse. I've literally had to disable my "--" autocorrect just to not be accused of using an LLM when writing. It's annoying.
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.
edward28 | 8 hours ago
monax | 8 hours ago
kijin | 8 hours ago
lnenad | 8 hours ago
madduci | 8 hours ago
monax | 8 hours ago
magicalhippo | 8 hours ago
monax | 8 hours ago
ThrowawayTestr | 7 hours ago
madduci | 7 hours ago
yjftsjthsd-h | 7 hours ago
M95D | 7 hours ago
eqvinox | 6 hours ago
g051051 | 8 hours ago
Pretty neat, though.
fbnszb | 7 hours ago
redvulps | 7 hours ago
monax | 7 hours ago
aruametello | 7 hours ago
tracker1 | an hour ago
my_throwaway23 | 7 hours ago
monax | 7 hours ago
spiffyk | 7 hours ago
monax | 7 hours ago
p_l | 7 hours ago
catapart | 7 hours ago
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?
monax | 7 hours ago
nxobject | 7 hours ago
DustinBrett | 6 hours ago
asveikau | 6 hours ago
I bet somebody has done that.
https://www.google.com/search?q=os+kernel+in+javascript
Seems like a small number of hobbyists have attempted.
I've heard of people doing this with other high level languages. Basically you need enough low level code to bootstrap a VM. Once you have that, you can make the high level language decide some logic that traditionally would be in C code, like manipulating page tables or whatever.
gwbas1c | 6 hours ago
I vaguely remember hearing about someone trying to use .Net in the Windows kernel.
The big problem is garbage collection: If I remember correctly, the fact that "any" operation can fail with an out of memory exception was a huge problem. Another problem was that random pauses for garbage collections in the kernel had major stability issues.
In short, I hope that the js kernel is for amusement and education; otherwise it would need a much more advanced garbage collector then earl 2000's .Net.
asveikau | 4 hours ago
Microsoft did that, it was called Longhorn. That release cycle was long delayed and they abandoned most of its ambitious projects, especially C# in the kernel, and the result was Windows Vista.
GC was not the only reason for the failure of that project. Someone could write a book about it. A lot of it was actually more about the organization of people. I also had heard from insiders that lack of ahead of time compilation was an issue. The other issue I remember hearing about was a complaint that Windows components were not layered cleanly and they ended up with circular dependencies when they tried to rewrite them.
I think it's possible to write a kernel with GC, and to still be judicious about memory usage with a GC language. And I say that as someone who happens to think that a big issue with modern software is that too many programmers are spending their whole education and career to depend on GC without thinking about it carefully. That is to say I'm already a skeptic of high-level languages and GC, but I will still afford that it is technically possible.
anonymars | an hour ago
> Microsoft did that, it was called Longhorn
Do you have any reference for that? Or are you confusing Longhorn with Singularity (https://en.wikipedia.org/wiki/Singularity_(operating_system)) / Midori (https://en.wikipedia.org/wiki/Midori_(operating_system))?
I suspect you're referring to the shell/internals, though, not the kernel (https://longhorn.ms/the-reset/#:~:text=Why%20start%20over,re...)
asveikau | an hour ago
danudey | 24 minutes ago
When security and reliability were suddenly key issues for Microsoft (to the extent that they ever were), it was obvious that what the Longhorn team had built was never going to meet that bar so they started over building off the Windows Server codebase instead.
Most of this story I remember from a video on YouTube of that old guy who worked at Microsoft since forever and left around the time of the Longhorn debacle, but a lot of it is corroborated in the Wikipedia article as well. https://en.wikipedia.org/wiki/Development_of_Windows_Vista
leoedin | 6 hours ago
tracker1 | an hour ago
tatskaari | 6 hours ago
Zambyte | 5 hours ago
monocasa | 2 hours ago
hajile | 6 hours ago
https://medium.com/@retrage/lkl-js-running-linux-kernel-on-j...
bayindirh | 7 hours ago
faxmeyourcode | 7 hours ago
> Prometheus stole fire from the gods and gave it to man. For this he was chained to a rock and tortured for eternity.
falcor84 | an hour ago
> If this makes you grin, you are probably holding the torch.
Smalltalker-80 | 7 hours ago
monax | 7 hours ago
ruined | 6 hours ago
outadoc | 7 hours ago
bwat49 | 7 hours ago
fenwick67 | 7 hours ago
lioeters | 7 hours ago
grougnax | 7 hours ago
GranPC | 7 hours ago
marijnz0r | 6 hours ago
rezmason | 7 hours ago
dfedbeef | 7 hours ago
ycombinatornews | 7 hours ago
Hilarious
pwdisswordfishy | 7 hours ago
monax | 6 hours ago
flopsamjetsam | 4 hours ago
rafram | 6 hours ago
eqvinox | 6 hours ago
What if it makes me recoil in horror? screams into the void
fnimick | 6 hours ago
monax | 6 hours ago
ruined | 6 hours ago
kiddico | 6 hours ago
epistasis | 5 hours ago
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...
p0w3n3d | an hour ago
I think he was trying to bend reality with words. I can see many apps that are running in electron on my laptop, each consuming 300MB+ (e.g. Spotify), while many other apps are written in native Swift for example, especially with the help of AI, giving the best performance possible...
Edit.
And prices of RAM nowadays...
pwdisswordfishy | an hour ago
They are consuming 300MB of RAM because they are built on Electron and the NPM ecosystem.
Decabytes | 6 hours ago
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 | 6 hours ago
sanufar | 6 hours ago
fnimick | 6 hours ago
cluckindan | 5 hours ago
xp84 | 4 hours ago
Note: 128GB of DRAM may add another million dollars to the build cost by 2027 at the current derivative of the $/GB curve
cluckindan | an hour ago
shepherdjerred | 6 hours ago
https://en.wikipedia.org/wiki/Java_processor
juancn | 6 hours ago
shevy-java | 5 hours ago
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.
notpushkin | 5 hours ago
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).
DJBunnies | 5 hours ago
watermelon0 | 2 hours ago
0) JavaScript must be abolished from the browser
pwdisswordfishy | an hour ago
Gnome Shell and Firefox/SeaMonkey/Mozilla Application Suite/Netscape 6+ (and Zotero[1]) are implemented on top of SpiderMonkey.
1. <https://news.ycombinator.com/item?id=46735616>
tracker1 | an hour ago
It's also a single, self-updating executable and includes a lot in the box. Including SQLite3.
raphaelmolly8 | 5 hours ago
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.
written-beyond | 5 hours ago
Not implying your comment is LLM generated, clearly it isn't but asking as a genuine question.
Kerrick | 4 hours ago
Typography nerds, which are likely overrepresented on HN, love both em dash and en dash, and we especially love knowing when to use each. Punctation geeks, too! If you know what an octothorp or an interrobang are, you've probably been using em dashes for a long time.
Folks who didn't know what an em dash was by name are now experiencing the Baader-Meinhof phenomenon en masse. I've literally had to disable my "--" autocorrect just to not be accused of using an LLM when writing. It's annoying.
geocar | 4 hours ago
xp84 | 4 hours ago
smetannik | 2 hours ago
moffkalast | 2 hours ago
>looks inside
>node modules
IshKebab | 2 hours ago
fennec-posix | 16 minutes ago