The main benefit they're giving is that you can use `npm` instead of `yum` or `aur` or whatever the package manager you use is. IMO, you're better off using Nix if you are tired of your package manager.
Why do you think NPM is "the most unreliable package manager"? I don't use Node, but I thought the general consensus was that it's one of the best out there. I'm genuinely curious.
No offense, but where on earth did you get that impression from? I have a feeling whoever told you that has either never used npm with a non-trivial project or was messing with you.
I've had more issues with npm in the last month than I've had with pip, gem, and apt combined over the last two years. "most unreliable package manager" is an apt descriptor.
If you've used it for anything non-trivial, then you probably should've been using a private registry - in which case you get the decentralized benefits of npm sans npmjs.org availability issues.
Is the issue just that npmjs.org is frequently unavailable? Surely any serious project will have their own mirror of NPM, PyPI, apt, yum, etc so they are not relying on third party servers they don't control to be able to do a build/deploy/whatever.
None taken. I got the impression from comments on HN and elsewhere. To be fair, those comments might've been from Node advocates, so they could've been skewed. Is one of the (main) problems that the registry is often unavailable?
I think npm gets praised by proponents based on how it integrates with the language and handles dependencies rather than on the reliability of the server.
Sorry for the late reply here, It feels like NPM's package mirrors go down almost every week and often for hours at a time. The whole thing feels thrown together - even the output from the installer colours successful commands as RED so when you are watching a build you think 'Oh crap somethings broken! - oh no, wait it's just NPM again...'
I was hoping that this would be about a unikernel for node.js, ala MirageOs, which would be quite interesting for running node directly on VMs, Xen, Raspberry Pi, and such.
A Linux distribution is an OS. Its an OS that shares considerable code and features with other related OS's, but that's true, e.g., of say "Windows" with respect to "Windows Server", which I think most people would agree are, in fact, OS's.
Honestly, it might be time to put the pejorative term "Linux distribution" to death. It was pretty true when there was Slackware and Debian, but the we're not talking about two stalks off of the same evolutionary branch anymore, but an entire ecosystem of different animals.
Modern "distributions" ship with vastly different libcs (bionic, newer vs older glibc, muslc), different userland runtimes (busybox, "GNU/Linux" with core utils, etc), different compilers (various branches of gcc, llvm increasingly), different init systems (SysV, upstart, systemd, etc), different security frameworks (AppArmor, SELinux), different display servers (X, Wayland, unfortunately Mir and SurfaceFlinger) and vastly different UIs (from Android, to GNOME and its fragmentations, to KDE and its fragmentations, LXDE and XFCE, and so forth). You can't even bet on the file system hierarchy being the same anymore, with aberrations like NixOS running around. The saddest part is that Linux is the most some of these operating systems have in common, and these days it can easily have the least overall impact on most of the users. These things are completely different animals, loosely bound by design contracts like FreeDesktop.org's various specs and Linux Standard Base specs which everyone violates in new and unique ways.
Not treating these operating systems as entirely different entities is being at best dishonest, and at worst is costing millions, perhaps even hundreds of millions of dollars in effort across the industry. You can't honestly target "Linux" as a platform because it's not a platform. If you've maintained, or especially if you've distributed any piece of software on "Linux" these days, you've seen the horrors.
I don't know anything about SurfaceFlinger, but why do you call out Mir here after referencing a vast amount of other components of a Linux distribution that all essentially do the same thing? Who knows, Mir could turn out better than Wayland.
Weird how everyone's happy for an abundance of choice, except when it's a display server or init system. Those two generate so much hate and I don't really get why.
The most obvious example of why Debian is an OS, not a "Linux distro," is because you can install the kfreebsd architecture and then you're not using Linux at all.
Not to say that the project doesn't look valuable, but I'm not sure if the project is still alive. See: https://github.com/NodeOS Latest commit was 4 months ago.
I thought the same thing, then noticed the only files in the repository are the readme and info for contributing. I'm not sure where the actual project source is.
Given that the NodeOS homepage linked to the thread title lists as one of the few bits of information about NodeOS that it is "hosted on Github / open and easy to contribute to - pull request friendly", I think the fact that none of the projects at https://github.com/NodeOS have been updated since May is a likely sign that the effort is dead.
I'd say Arch is for people who have the time to learn and care how most parts of the OS work. I use it because I like to heavily customize everything, and want complete control over how everything is done.
I don't see why codereflection needs to spell it out. The problems with npm, and JavaScript in general, are quite apparent to anyone who has used them. And if you haven't used them, a quick search engine search will turn up this information many times over.
It'd make sense to ask for such clarification if the information truly wasn't available elsewhere, and accessible with a quick search. But that's obviously not the case.
It's pointless to rehash this obvious stuff over and over and over and over again.
It'd be good if there were a canonical "Why npm sucks" article, like the "fractal of bad design" one for PHP.
This one seems like a fairly reasonable candidate: http://www.jongleberry.com/why-i-hate-npm.html (though the "nested dependencies" bit needs much more swearing, and I disagree with the last paragraph suggesting things in Ruby and Python land are just as bad).
In the last paragraph there, is he saying that Golang is 'bad' because it doesn't have a package manager? Does it need one? I always assumed 'go get' was enough.
It is certainly isn't obvious to me. NPM is the best package manager I have used for a specific language. I do think there are things that can be improved, like everything else, but overall I think it is pretty good. And the vast majority of complaints I have seen are just nitpicks. So yes I would be very curious to know what you think is so obviously broken with it.
While I don't hate npm, there are better examples of how to do package management. For example, Nuget gets a lot of things right with no nested dependencies.
You're reading too much into my statement. I said npm frustrates me, I didn't say NPM IS BAD.
I do not feel this is the proper place to go into why NPM frustrates me so much, but on a high level, I'll tell you that it has much to do with nested dependencies & lack of support for seeing more than 1 version number on their website. Bower is even worse on the latter. Look at @bshimmin's link, http://www.jongleberry.com/why-i-hate-npm.html, I share a lot of the same concerns.
It reminds me of Chrome OS and Firefox OS. These all are based upon the Linux kernel, so they could potentially offer a very rich user experience like so many more traditional Linux distributions do. Yet they intentionally cripple themselves into being limited, JavaScript-only platforms.
This would be understandable if, say, storage space was expensive, like it was in the 1980s, and the software had to be kept lean and limited. But that's clearly not the case today, even when it comes to low-end smartphones.
The same goes for runtime performance. It'd be one thing if software written in JavaScript was consistently and significantly faster than software written in C, C++, and other commonly used languages. But that just isn't the case. Unless we're looking at highly tuned and highly unrealistic benchmarks that even the JavaScript VM authors have focused on making run fast, JavaScript's performance is quite bad.
It would be understandable if perhaps the user experience could be improved in some way by them providing superior alternatives to the traditional userland software offered by Linux distributions. Yet this isn't the case, either, because some of the biggest complaints with Chrome OS and Firefox OS are that the bundled software is awful, and users have no real recourse due to the very limited environment that both offer.
As far as I can tell, users just can't win with a system like this. The kernel is powerful, but this power is isolated and kept inaccessible. The userland experience is much worse than what one would get if just using a traditional Linux distro, and running the JavaScript software on top of that. The benefit to the user just isn't apparent.
Well, with FirefoxOS, you don't have Android's Dalvik nonesense nor iOS's restrictive marketplace. They needed some userland language, since the isolation keeps security high. These mobile computers aren't used in a security conscious way, and many developers are unscrupulous in the environments. Give them the power to install rootkits, and they will.
As a concept, I guess this can be called an OS, but at the present moment, it is pretty far from one. Right now it seems like this is basically a work-in-progress replica of BusyBox built on Node.
No doubt JavaScript's past, present, and future is intertwined with the web, but really it's an independent programming language. It's not like there are primitives for divs and tables.
And by an accident of history, it also happens to be the world's most popular programming language and overall a decent scripting language, so I can't see why its web association should make it any less OS-ready than any other language.
Plus, Node's async model lends itself implementing lower-level OS features (not that they are present so far in NodeOS).
We are forced to use poorly-designed legacy languages on the "open" web, but why would you torment yourself with them when you are not limited outside of the "open" web?
An actual minimalist kernel booting to node might be interesting. But this isn't that. This just looks like plain node and npm, except locked down and made complicated for no reason.
I haven't dabbled in Node yet; my main source of hesitation was I've been told npm doesn't cryptographically sign packages. If npm as a package manager is a selling point, I would hope this has been corrected (or had been all along).
Yes? Sort of .. is your distribution an OS? (Should the distro's source repo change every time the installer is rebuilt from new upstream packages? I don't think so)
Someone has been working on this repo for the last 22 days and they merged their changes back in #12. Possibly in response to allegations that the Node-OS project is dead.
I would expect most of the active development to be in the upstreams of this project (npm, linux kernel), it doesn't seem to be dead at any rate. Just not very fast-paced or popular.
How is this useful exactly? I suppose there are JS bindings for GNOME (if I remember correctly) so getting a GUI stack wouldn't be that difficult, if that's where they want to go.
I just don't see how using NodeOS would be an advantage over any other *NIX distro.
It isn't useful at all. It is an experiment and a hobby. For those of us who use javascript everywhere we already can, it is natural to want to push it further and see what we come up with.
I am an outsider who is starting to touch javascript but I have my history in scripting and numerical sims. Is all this stuff about node.js really something revolutionary or is it hype?
My experience with node-webkit leads me to believe it could, once ironed out, actually become a popular way for web developers to get their start with client-side apps.
As far as Node.js as a server-side scripting language? Idk. I'm a PHP guy.
This is not an operating system written in JS, it just reuses the NPM package manager, which is part of the Node.JS developer community. So npm-os would have been a better name, imho.
Yeah... Anyone who makes a valid point or say something possibly humorous gets downvoted by overly sensitive HN readers. (Like this comment inevitably will, too.)
