111–120 of 144 posts
What would it take to get this running on iOS and Android?
You might be able to add QEMU support to this, and then run it on an Android device if you have root. But it would perform terribly because mobile chips generally don't have virtualization extensions and ARM as a virtualization host is a pretty immature platform.
TL;DR - far too much to be practical.
If this works, this is fantastic. Getting away from the stupidly complex abstractions around Docker is a welcome change, especially if we can still package and deploy immutable images. We already manage containers like tiny VMs, so ditching the abstractions should simplify life a bit.
Not sure what you mean.. could you give some examples?
In my experience, people prefer Docker over VM's because they _like_ the abstractions and tooling associated with it. It's a lot friendlier to developers and makes immutable infrastructure a much more realistic goal for ops folks, IMO.
Earlier quoted context omitted.
Interesting. So what makes it virtualization? What's "virtual" or "virtualized" about it?
One could argue that the key of virtualization is that a piece of software is run in an environment that pretends to be something else than the actual base system. A VM hypervisor runs an operating system in a way that it looks like as it is running alone on a physical machine, with some fake devices. From inside a container, similarly the environment is fake: it can't see processes outside the container, it's view o…
This is cool. For dev, the docker runtime consumes an enormous amount of host system resources. Even with a 16gb RAM host machine, docker is really resource heavy for a development environment. If this can cut down on host system resource usage, that's a major win.
Earlier quoted context omitted.
Interesting. So what makes it virtualization? What's "virtual" or "virtualized" about it?
The kernel
Why does everything in node have to have all the dependencies in the world? ``` @sindresorhus/is JSONStream ansi-regex ansi-styles archive-type argparse asn1 async balanced-match base64-js bcrypt-pbkdf bl bluebird brace-expansion buffer buffer-alloc buffer-alloc-unsafe buffer-crc32 buffer-fill buffer-from cacheable-request camelcase caw chalk chownr cliui clone-response color-convert color-name commander concat-map c…
Yesterday a friend of mine told me about how they got a Node.js application from a vendor that was about 3 MiB, and after running npm install, it was over 1 GiB. I half-jokingly said that Node apps are the new ZIP bombs.
Earlier quoted context omitted.
good luck to your friend with repeatable installations :P
"If you wish to make apple pie from scratch, you must first create the universe" - Carl Sagan the npm ecosystem takes this quite literally, for better or worse.
Why does everything in node have to have all the dependencies in the world? ``` @sindresorhus/is JSONStream ansi-regex ansi-styles archive-type argparse asn1 async balanced-match base64-js bcrypt-pbkdf bl bluebird brace-expansion buffer buffer-alloc buffer-alloc-unsafe buffer-crc32 buffer-fill buffer-from cacheable-request camelcase caw chalk chownr cliui clone-response color-convert color-name commander concat-map c…
These are the first-level dependencies: chalk: log formatting dockerode: docker API download: file download? fs-extra: functions like mkdirp, emptyDir hasbin: check if bin exists in PATH js-yaml": yaml parser mustache: templating node-virtualbox: VB API progress: terminal progress bar simple-git: Git API sudo-prompt tar uuid It looks reasonable at first sight. Of all these, fs-extra is the only one you can argue shou…
The topic has come up, but I'm generally against it; sure, we could spend all the resources on doing all the filtering and analysis and change management that it would take to establish a sane package base that we could officially support for internal development work... But why? We do it for other languages, but Node has a lot of "my first programming language" bs going on in the ecosystem. I strongly suspect that allowing Node development would be a net negative for our company.
Earlier quoted context omitted.
These are the first-level dependencies: chalk: log formatting dockerode: docker API download: file download? fs-extra: functions like mkdirp, emptyDir hasbin: check if bin exists in PATH js-yaml": yaml parser mustache: templating node-virtualbox: VB API progress: terminal progress bar simple-git: Git API sudo-prompt tar uuid It looks reasonable at first sight. Of all these, fs-extra is the only one you can argue shou…
This is exactly why we don't allow our employees to use Node.js for company software development, even though in theory a fair chunk of the runtime is our own software that we maintain. But the npm ecosystem has a really awful signal-to-dogturd ratio, and developers appear to put very little effort into critically analyzing their dependencies. The topic has come up, but I'm generally against it; sure, we could spend…
Earlier quoted context omitted.
You're confusing JS and NodeJS. NodeJS has more stdlib stuff; opening files, for example.
Virtually everything is a dependency in JavaScript, whether you're using node.js or not. One need look no further than your citation of `open()` as the proof that the nodejs environment "has more stdlib stuff". If the operating environment can run in a context where file IO happens, a native file open function is about the most basic baseline there is. It's absolutely not a good look for "well, we have `open()`!" to…
...which it isn't, given that the "fs" module has a wide variety of features much beyond an equivalent to open().