This comment seems correct. No commits in years [0], but more telling is issue #441 [1]:
> Q: Is nodeOS an abandonned project?
> A: Unluckily, sort of. I've tried sometimes to retake it, but work has absorved me so much that don't have time to engage on long-term side projects, and size of NodeOS itself give me a lot of respect. Obviously this has not been the only problem, I failed to communicate and delegate some work to the community, although they were willing to do so. If only I could get some extra motivation to retake it, like some funds or something, or at least to focus myself on the project and get over to my fears... :-/
So, it seems that it's stalled and with some love it might be able to be resurrected. But even the issue report is over 1 year old.
I'd be curious to learn what kinds of safeguards various package managers of Linux distros have employed against supply chain attacks on individual maintainers who might try to poison certain popular packages if compromised?
Specifically, I'd imagine NPM might actually be a bit better than many distro's package repos due to the post left-pad era changes they put in place to make packages more... immutable and tamper-resistant, so the only way for a new malicious package to reach users is for those users to actually explicitly update to the new malicious versions. But being not even remotely familiar with how Linux package repos are updated/maintained, I'm probably missing a lot of nuance.
Seems feasible to create a limited mirror of NPM with only hand-audited packages (and versions). At that point it's not really different from the repositories managed by OS maintainers.
We have a project which's converted into a monorepo due to need of syncing and sharing.
Imaging you have a web app and a mobile app, when the web app has changes, u need to sync changes to mobile app as well. What's the best way to do it ?
Besides javascript, i can't know a better way then. Our team has only 2 devs working on all server, web and mobile appp.
If there are only two people in your dev team then you absolutely wouldn’t be writing OS components as well as web apps regardless of the languages natively supported by the OS.
Oh yea let's build an OS where we can just import our kernel-mode drivers from the repository of quality code that is NPM. I mean what could possibly go wrong, right?
I'm sorry but we need less NodeJS and JavaScript in this world, not more.
You're just picking something to hate and it's not even correct.
It's not true that OS==kernel. The kernel is Linux, and this is replacing the GNU stuff around it with something else. The result is a new kind of OS. But nobody said that any privileged code will be written in JS.
The frontend of Gnome shell at least. The API that the JavaScript consumes is still low level.
My experience with Gnome shell is that third party extension, written in JavaScript, is often leaky and leads to massive slowdowns in the desktop and requires a restart of gnome shell at least once a day. Which leads to the conclusion not to use third party extensions, thus removing the benefit of having a scriptable shell.
It looks dead. I think they chose the wrong approach in lots of ways, but it wasn't that far from a JS (and Typescript) based OS on top of Linux that is actually a good idea.
ChromeOS is kind of close to what I'd want, if you could remove Google from it. (I actually like ChromeOS, nearly perfect for my kid's computer)
Firefox OS was also kind of close, but they missed in a lot of ways.
Here are the features of some OS I wish existed:
Open source and not primarily controlled by Apple or Google or Microsoft of Facebook or whatever.
JS and Typescript are essentially native and are the primary ways of building apps, but WASM would be available if you need machine code.
The same JS engine runs in the browser as for running applications. The same rendering engine works inside the browser and to render "native" apps that do any drawing to the screen. Preferably, you could choose to run on one of several browser engines
Most apps that run as native apps can, without much extra work, run as web apps, and vice versa.
The UI isn't built on a framework that might fall in popularity. So not React or Angular or Vue or whatever. If people want to use those in their apps, they are there, but core stuff for the UI avoids relying on them.
That's all I can think of for now. Beyond "design it really, really well and make a slick feeling but non-limiting front end experience." Which is hard.
(sorry to those with unbridled hate for JS and even Typescript)
We’ve seen how Electron performs. The only reason VSC doesn’t totally suck is because a lot of it is still native code. I can’t even imagine how crappy it would be building an entire OS out of that stuff.
And you’re never going to escape the needs for another systems language because unless you find a way of writing non-memory managed code with pointers and inlined assembly in JavaScript, that language simply isn’t going to cut it. And on top of that you’d need a compiler that can compile machine code just to bootstrap node in the first place.
I’m all for experimental operating systems but there’s a reason systems languages differ in design to web scripting languages and really we should be using the languages that suit each domain the best rather than simply putting JavaScript everywhere because we are too lazy to learn anything else.
There's very little native code in VS code: https://github.com/microsoft/vscode It's all typescript, even the main editor component monaco. You might be thinking of the atom editor which tried to do more native code for speed of editing but AFAIK atom has kind of been shelved and not developed anymore.
Search, language server engines, even code reformatting, all the stuff that really separates VSC is an external executable and thus not part of Electron.
If any of these fanboys spent even 5 minutes looking at the config of VSC (never mind the source) they’d see just how many references to other binaries there are.
I’ve recently got back onto Java project after few years and Intellij feels crazy fast whan compared to VS Code. And it has 2x IDE functionalities built in.
As much as I love JS on web and backend via Node, I really hate desktop apps in Electron.
> VSCode is an IDE, features are organized by extensions. Intellij's products work the same.
The important bit here probably has something to do with first party vs third party extensions when talking about the IDE functionality. Also, what's included in the base install is also important if you want to talk about using either as a text editor.
Lots of different IDEs (and nowadays other tools too) for different tech stacks, although all of them are based on pretty similar tech/platform. E.g. if you install a few plugins, you can get parts of the WebStorm functionality in PhpStorm or IntelliJ or whatever, even if it might not necessarily be 100% the same. Some other IDEs out there also follow this approach, providing first party support for certain modules, like Eclipse also has similar packages (installable for free in the base product, though) https://www.eclipse.org/jdt/
In contrast VSC has an extension manager that has both first party and third party extensions available and doesn't necessarily pigeonhole you as much towards a particular extension, even though in practice you might still just go for whatever is recommended, which in many cases will be the most popular (and by proxy, most well supported) extension available for whatever it is that you need. However, the downside of this is more fragmentation and having more difficulty in ensuring consistent behaviour, since what's included in IntelliJ and Eclipse JDT is probably a bit better known than what your unique install of VSC will have.
However, at the same time, Eclipse, JetBrains products (all of them) and even other IDEs like NetBeans all fail at the text editor use case. Want to edit an .ini/.env/.yaml/.json file really quickly? Unless you have the IDE already open, the startup will be slow and cumbersome, whereas VSC wins for such use cases hands down. For example, in situations where i have a Git repo with some Ansible scripts, or some GitLab CI stuff for DevOps, i would almost never reach for anything apart from VSC (Notepad++ or other native editors on other platforms are also okay, though VSC is surprisingly consistent most of the time).
Thus, VSC can be a text editor, it can (mostly) be an IDE, though for specific tech stacks and codebases of certain complexity, it will fall behind both VS and JetBrains products, maybe even Eclipse, NetBeans etc. For example, in IntelliJ i can apply a whole plethora of code inspections, there are lots of helpful hints and fix suggestions for popular frameworks (like Spring/Spring Boot/Jakarta) alongside pretty smart autocomplete. Not only that but i can do refactoring across the entire codebase of thousands of files and hundreds of thousands of lines of code with a lot of confidence about the end result. I doubt that i'd be able to work on some of the enterprise stuff that IntelliJ makes easy to reason about in any other editor, at least so successfully - NetBeans straight up crashes when i try to open 30 files and do refactoring, whereas VSC Java plugin felt a tad rudimentary when i last checked (even though that was a while ago).
In summary, it's definitely not just semantics in my view, each tool has its strengths and drawbacks - in practice you might use both for different use cases and have a pleasant time thanks to that.
I personally don't understand this complaint. I use VSCodium on a daily basis with numerous extensions, and it is far faster than Atom. Yes it doesn't have the speed of properly configured emacs but I've also had emacs configs that take longer to load than codium. Codium is more than snappy enough with my build out to do all of my work effectively, I don't notice any typing lag at all
If you compare it to Atom, then yes, it’s fast. But compare it to anything native and it’s unusable. I’m using Sublime and switching to VS code hurts my brain. It just feels wrong. You can feel that there’s some time between pressing a key and character showing.
VSCode literally runs in the browser with identical performance to the Electron app (because aside from some differences in APIs, the runtime is pretty much the same). Try GitHub Codespaces and you'll see.
One common marketing gimmick within the JavaScript community is to brand your project "lightweight", just like this project. JavaScripter’s desperately search for that because their ecosystem is the total opposite.
Total collapse? Ha, thanks for the laugh. Snark aside, it’s nowhere near total collapse. It’s not without its problems of course but things are relatively fine compared to other package management solutions in use with other languages.
No, I wrote total opposite. Nothing else. Never changed it.
I wrote about the overuse of "lightweight" in the JavaScript community and just that fact that building an OS on top of npm can hardly be classified as "lightweight", thus logically npm is the opposite of lightweight, bloated.
Why would I write total collapse when contrasting lightweight? Doesn’t make any sense.
You misread. That happens, I do that too time to time. But own it when it happens.
I read it as “total opposite” and unless the GP has found a way of rewriting both my memory and bypassing HNs automatic hard limit of a 2 hour edit window, I’d say the error is yours.
Plus total collapse doesn’t even make sense given the context of post whereas total opposite does. So that alone should have prompted you to re-read their post.
I believe an OS based on WASM could have merit. For WASM, there is the AssemblyScript language, which was inspired by TypeScript but runs faster because it avoid the complexity of JavaScript runtimes.
Came here to say this. Beyond Rust and AssemblyScript, there are quite a few other programming languages that target WASM, meaning that WASM is a good candidate for that holy grail, the unified environment where you can write your stuff in 'any' language and re-use and talk to stuff written in 'any' language without relying on relatively clunky, type-challenged and slow IPC.
Yeah when I was an ITSM consultant. ServiceNow uses JS extensively. Those were the ECMA 4 and ECMA 5 times to be honest though. I guess a lot has changed since then.
81 comments
[ 1.9 ms ] story [ 156 ms ] thread> Q: Is nodeOS an abandonned project?
> A: Unluckily, sort of. I've tried sometimes to retake it, but work has absorved me so much that don't have time to engage on long-term side projects, and size of NodeOS itself give me a lot of respect. Obviously this has not been the only problem, I failed to communicate and delegate some work to the community, although they were willing to do so. If only I could get some extra motivation to retake it, like some funds or something, or at least to focus myself on the project and get over to my fears... :-/
So, it seems that it's stalled and with some love it might be able to be resurrected. But even the issue report is over 1 year old.
[0] https://github.com/NodeOS/NodeOS
[1] https://github.com/NodeOS/NodeOS/issues/441
edit: formatting
SCNR
This is interesting, in the light of recent supply chain attacks on npm. How safe is a npm-based OS?
Specifically, I'd imagine NPM might actually be a bit better than many distro's package repos due to the post left-pad era changes they put in place to make packages more... immutable and tamper-resistant, so the only way for a new malicious package to reach users is for those users to actually explicitly update to the new malicious versions. But being not even remotely familiar with how Linux package repos are updated/maintained, I'm probably missing a lot of nuance.
NodeOS 0.04
Your welcome
This is 100% despicable. I thought my own imagined PowerShell based Linux Distro would be insidious enough, but this, this is an absolute, pure evil.
Write your function once then u can import to use it everywhere, from server to frontend, mobile or desktop app. Why reinventing the wheel ?
Imaging you have a web app and a mobile app, when the web app has changes, u need to sync changes to mobile app as well. What's the best way to do it ?
Besides javascript, i can't know a better way then. Our team has only 2 devs working on all server, web and mobile appp.
Hilarious stuff.
Edit: and getting flagged for pointing out how ridiculous these idiots are too. Fanboys must be out in force this weekend.
I'm sorry but we need less NodeJS and JavaScript in this world, not more.
It's not true that OS==kernel. The kernel is Linux, and this is replacing the GNU stuff around it with something else. The result is a new kind of OS. But nobody said that any privileged code will be written in JS.
My experience with Gnome shell is that third party extension, written in JavaScript, is often leaky and leads to massive slowdowns in the desktop and requires a restart of gnome shell at least once a day. Which leads to the conclusion not to use third party extensions, thus removing the benefit of having a scriptable shell.
ChromeOS is kind of close to what I'd want, if you could remove Google from it. (I actually like ChromeOS, nearly perfect for my kid's computer)
Firefox OS was also kind of close, but they missed in a lot of ways.
Here are the features of some OS I wish existed:
Open source and not primarily controlled by Apple or Google or Microsoft of Facebook or whatever.
JS and Typescript are essentially native and are the primary ways of building apps, but WASM would be available if you need machine code.
The same JS engine runs in the browser as for running applications. The same rendering engine works inside the browser and to render "native" apps that do any drawing to the screen. Preferably, you could choose to run on one of several browser engines
Most apps that run as native apps can, without much extra work, run as web apps, and vice versa.
The UI isn't built on a framework that might fall in popularity. So not React or Angular or Vue or whatever. If people want to use those in their apps, they are there, but core stuff for the UI avoids relying on them.
That's all I can think of for now. Beyond "design it really, really well and make a slick feeling but non-limiting front end experience." Which is hard.
(sorry to those with unbridled hate for JS and even Typescript)
And you’re never going to escape the needs for another systems language because unless you find a way of writing non-memory managed code with pointers and inlined assembly in JavaScript, that language simply isn’t going to cut it. And on top of that you’d need a compiler that can compile machine code just to bootstrap node in the first place.
I’m all for experimental operating systems but there’s a reason systems languages differ in design to web scripting languages and really we should be using the languages that suit each domain the best rather than simply putting JavaScript everywhere because we are too lazy to learn anything else.
You should have gone through https://github.com/microsoft/vscode/blob/main/package.json instead of main repo.
Search, language server engines, even code reformatting, all the stuff that really separates VSC is an external executable and thus not part of Electron.
If any of these fanboys spent even 5 minutes looking at the config of VSC (never mind the source) they’d see just how many references to other binaries there are.
It’s a horrible text editor. Maybe a nice IDE but horrible editor.
It's a shittier, more bloated Emacs.
As much as I love JS on web and backend via Node, I really hate desktop apps in Electron.
The important bit here probably has something to do with first party vs third party extensions when talking about the IDE functionality. Also, what's included in the base install is also important if you want to talk about using either as a text editor.
For example, have a look at JetBrains products: https://www.jetbrains.com/products/
Lots of different IDEs (and nowadays other tools too) for different tech stacks, although all of them are based on pretty similar tech/platform. E.g. if you install a few plugins, you can get parts of the WebStorm functionality in PhpStorm or IntelliJ or whatever, even if it might not necessarily be 100% the same. Some other IDEs out there also follow this approach, providing first party support for certain modules, like Eclipse also has similar packages (installable for free in the base product, though) https://www.eclipse.org/jdt/
In contrast VSC has an extension manager that has both first party and third party extensions available and doesn't necessarily pigeonhole you as much towards a particular extension, even though in practice you might still just go for whatever is recommended, which in many cases will be the most popular (and by proxy, most well supported) extension available for whatever it is that you need. However, the downside of this is more fragmentation and having more difficulty in ensuring consistent behaviour, since what's included in IntelliJ and Eclipse JDT is probably a bit better known than what your unique install of VSC will have.
However, at the same time, Eclipse, JetBrains products (all of them) and even other IDEs like NetBeans all fail at the text editor use case. Want to edit an .ini/.env/.yaml/.json file really quickly? Unless you have the IDE already open, the startup will be slow and cumbersome, whereas VSC wins for such use cases hands down. For example, in situations where i have a Git repo with some Ansible scripts, or some GitLab CI stuff for DevOps, i would almost never reach for anything apart from VSC (Notepad++ or other native editors on other platforms are also okay, though VSC is surprisingly consistent most of the time).
Thus, VSC can be a text editor, it can (mostly) be an IDE, though for specific tech stacks and codebases of certain complexity, it will fall behind both VS and JetBrains products, maybe even Eclipse, NetBeans etc. For example, in IntelliJ i can apply a whole plethora of code inspections, there are lots of helpful hints and fix suggestions for popular frameworks (like Spring/Spring Boot/Jakarta) alongside pretty smart autocomplete. Not only that but i can do refactoring across the entire codebase of thousands of files and hundreds of thousands of lines of code with a lot of confidence about the end result. I doubt that i'd be able to work on some of the enterprise stuff that IntelliJ makes easy to reason about in any other editor, at least so successfully - NetBeans straight up crashes when i try to open 30 files and do refactoring, whereas VSC Java plugin felt a tad rudimentary when i last checked (even though that was a while ago).
In summary, it's definitely not just semantics in my view, each tool has its strengths and drawbacks - in practice you might use both for different use cases and have a pleasant time thanks to that.
I wrote about the overuse of "lightweight" in the JavaScript community and just that fact that building an OS on top of npm can hardly be classified as "lightweight", thus logically npm is the opposite of lightweight, bloated.
Why would I write total collapse when contrasting lightweight? Doesn’t make any sense.
You misread. That happens, I do that too time to time. But own it when it happens.
Plus total collapse doesn’t even make sense given the context of post whereas total opposite does. So that alone should have prompted you to re-read their post.
<https://www.assemblyscript.org>, <https://leanylabs.com/blog/assemblyscript-intro>
Came here to say this. Beyond Rust and AssemblyScript, there are quite a few other programming languages that target WASM, meaning that WASM is a good candidate for that holy grail, the unified environment where you can write your stuff in 'any' language and re-use and talk to stuff written in 'any' language without relying on relatively clunky, type-challenged and slow IPC.
So what exactly has better long term popularity than React/Vue/Angular? We're at about 5+ years of those being the big three...
curious if there is practical use for this kind of systems
[1]: https://en.wikipedia.org/wiki/Lisp_machine