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

111–117 of 117 posts

Re: UEFI Bindings for JavaScript

#111

Post by [deleted] »

anonymars wrote: post #84
asveikau wrote: post #75

Earlier quoted context omitted.

> 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 orga…

> trying to use .Net in the Windows kernel. > 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/#:~:tex…

[deleted]

Re: UEFI Bindings for JavaScript

#112

Post by bpavuk »

BobbyTables2 wrote: post #106
spijdar wrote: post #100

Earlier quoted context omitted.

Funny, I've always found it interesting how "on point" it was... Granted, yeah, we never (or haven't yet) really transitioned to running "full legacy software" inside the browser, or at least it's not common place. That said, I've seen people compile Wine to wasm, Linux to wasm, and lots of other things to wasm, and run em in a browser. Many of the "fake" demos could be done for real now. The one aspect that remains…

We already can execute DOS / Win 3.1 in QEMU in the browser. Probably wouldn’t be too hard to boot Linux (under QEMU compiled for wasm), and then fire up a Windows 95 VM using QEMU TCG … Could repeat this a few times - Inception style…

yep, and 528491 as a password for everything :)

Re: UEFI Bindings for JavaScript

#113

Post by jpc0 »

pwdisswordfishy wrote: post #85
p0w3n3d wrote: post #83

Earlier quoted context omitted.

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... Edit. And prices of RAM nowadays...

Those apps are not consuming 300MB of RAM because they are written in JS. JS is running on microcontrollers and the James Webb Space Telescope. They are consuming 300MB of RAM because they are built on Electron and the NPM ecosystem.

There is a pretty significant difference between the way JS is used there and in electron apps.

This might be what you were getting to but I tend to agree with the idea of place all the interaction logic in a high kevel language and get the performance where it's needed.

Electron does not do that and neither does the people developing electron apps most of the time. I doubt many people throwing electron apps together chose to do that so they can put their CPU intensive code in C/C++/Rust/swift, they want to erite everything in JS.

What should happen is the bare minimum needs to be in JS and the rest in an efficient compiled language.

I mean even the browser does that, the DOM API hands off to lower level libraries for multimedia etc.

Re: UEFI Bindings for JavaScript

#116

Post by just_testing »

pwdisswordfishy wrote: post #85
p0w3n3d wrote: post #83

Earlier quoted context omitted.

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... Edit. And prices of RAM nowadays...

Those apps are not consuming 300MB of RAM because they are written in JS. JS is running on microcontrollers and the James Webb Space Telescope. They are consuming 300MB of RAM because they are built on Electron and the NPM ecosystem.

Wait a second, JS in James Webb Space Telescope?? Doing what? I'd love to hear about its usecases in the telescope. Is there any blog post about it?

Re: UEFI Bindings for JavaScript

#117

Post by gwbas1c »

asveikau wrote: post #101
gwbas1c wrote: post #98

Earlier quoted context omitted.

> I think it's possible to write a kernel with GC, and to still be judicious about memory usage with a GC language. ... but I will still afford that it is technically possible. I need to split some hairs for a bit: Do you mean what is colloquially referred to as "GC", as in the dotnet / Java / Javascript / golang "mark-and-sweep", fully-automatic style? Or do you mean other automatic memory management systems, which…

Given that we are talking about JavaScript, I meant the former. The latter is pretty much the status quo in terms of the state of the art. Most kernels aren't built with automatic reference counting, reference counted objects are plentiful even if more manual, but the automatic part is trivial to add to a C++ code base using smart pointers for example, and things like rust or apple ARC can also do it. I think the for…

According to https://en.wikipedia.org/wiki/Lisp_machine

> These machines had hardware support for various primitive Lisp operations (data type testing, CDR coding) and also hardware support for incremental garbage collection.

That being said, hardware garbage collection never really took off. When I look at GC languages they all have significantly different memory models, so I can see why. (For a more modern take on this, look into why dotnet can't use the proposed WASM garbage collector. Dotnet needs more metadata and finalizers, which WASM's GC doesn't provide.)

But getting back to a Javascript kernel with GC: I would think "stop the world" pauses would cause non-deterministic issues? (IE, if an interrupt has a long pause due to a GC?) It might only work if the kernel borrowed techniques from "real time Java" programming techniques?

Post reply on HN