I did something similar with TCL, the basis was using an extension I wrote to handle the UNIX stuff [0]. It operated an On-Premises cloud environment appliance, and `init` was just a TCL script (at one point it was a statically linked binary with the init script embedded, but that turned out to be overkill)
These things are essentially the opposite of one another. Bellard's project is a PC emulator in JavaScript. Compiling things to wasm is pretty trivial now, but jslinux was much more impressive when it came out. It actually still is, for reasons you can see in the technical notes: https://bellard.org/jslinux/tech.html
This project, on the other hand, is the opposite (and kind of a joke): a set of Linux utilities mostly written in JavaScript.
Reading the code, I was surprised to see that cd was implemented by calling out to the os library. I assumed that was something the shell or at least userspace handled. At what level does the concept of a “current directory” exist?
It's at the kernel level. Each process has its own current working directory. On Linux, these CWD values are exposed at `/proc/[...]/cwd`. This value affects the resolution of relative paths in filesystem operations at a syscall level.
Interesting. I've been using Unix systems for 30 years and never noticed this.
On my Fedora system, /usr/bin/cd is just a shell script that invokes the shell builtin:
#!/usr/bin/sh
builtin cd "$@"
I suppose it could be useful for testing whether a directory exists with search permissions for the current user safely in a multithreaded program that relies on the current directory remaining constant.
Yeah, it's typically a shell built-in since you'd want cd to change the cwd for the shell process itself. Child processes (like commands being executed in the shell) can inherit the parent shell's cwd but AFAIK the opposite isn't true.
This doesn't technically answer the question: POSIX doesn't concern itself with the kernel interface, only with the libc. Most POSIX systems have a kernel with a syscall interface that mirrors the libc API so that these libc functions are just syscall wrappers, but nothing technically prevents the current working directory to be a purely userspace concept maintained by the libc where all relative paths passed to filesystem functions are translated into absolute paths by the libc function before being passed to the kernel via syscall.
But yes, in the BSDs, Linux and Windows, the kernel has a concept of a current working directory.
Is this getting downvoted only because I referred to POSIX rather than UNIX? I'm more familiar with POSIX, but I'm 99% sure the UNIX standard also doesn't say anything about the kernel interface...
Very cool. Good use of quickjs, although it would have been cool if it somehow didn’t need a libc and just used the syscall interface. Makes me want to give that a try.
I remember some core Unix utilities reimplemented in Perl, mainly done for Win32 systems back in the day. OFC the performance coudn't compete with the ones written in C, but it was good enough.
I guess there are related projects such as busybox which contain a collection of utilities implemented in a single binary. There are others such as toybox, and various alternatives in different languages, or with different licenses to choose from.
We’re roughly on schedule. https://www.destroyallsoftware.com/talks/the-birth-and-death...
Slightly late according to other predictions
https://xkcd.com/1508/
I did something similar with TCL, the basis was using an extension I wrote to handle the UNIX stuff [0]. It operated an On-Premises cloud environment appliance, and `init` was just a TCL script (at one point it was a statically linked binary with the init script embedded, but that turned out to be overkill)
[0] https://chiselapp.com/user/rkeene/repository/tuapi/doc/trunk...
Check out this:
https://bellard.org/jslinux/vm.html?url=alpine-x86.cfg&mem=1...
and
https://bellard.org/jslinux/
By the famous Fabrice Bellard who is the creator of QuickJS, QEMU, FFMPEG and many other brilliant and fascinating tools!
https://bellard.org/
These things are essentially the opposite of one another. Bellard's project is a PC emulator in JavaScript. Compiling things to wasm is pretty trivial now, but jslinux was much more impressive when it came out. It actually still is, for reasons you can see in the technical notes: https://bellard.org/jslinux/tech.html
This project, on the other hand, is the opposite (and kind of a joke): a set of Linux utilities mostly written in JavaScript.
> tiny project for building a tiny Linux distribution
I am working something similar in Go, and writing an educative blog post series about it: https://serversfor.dev/linux-inside-out/
I'm enjoying the articles! I went through the exercise and it was my first time running my own executable on PID 1. That was fun and educational.
It’s never early to prepare for JavaScript complete takeover.
Reading the code, I was surprised to see that cd was implemented by calling out to the os library. I assumed that was something the shell or at least userspace handled. At what level does the concept of a “current directory” exist?
It's at the kernel level. Each process has its own current working directory. On Linux, these CWD values are exposed at `/proc/[...]/cwd`. This value affects the resolution of relative paths in filesystem operations at a syscall level.
It’s also generally a shell builtin. Though you do find an executable called cd too for compatibility reasons.
Interesting. I've been using Unix systems for 30 years and never noticed this.
On my Fedora system, /usr/bin/cd is just a shell script that invokes the shell builtin:
I suppose it could be useful for testing whether a directory exists with search permissions for the current user safely in a multithreaded program that relies on the current directory remaining constant.Yeah, it's typically a shell built-in since you'd want cd to change the cwd for the shell process itself. Child processes (like commands being executed in the shell) can inherit the parent shell's cwd but AFAIK the opposite isn't true.
Wait, how did the `cd` executable used to work in old Unix? Did it instruct the kernel to reassign the CWD of the parent process?
The original UNIX shell (Thompson Shell) had chdir as a builtin, so I’d wager it’s always been a builtin.
https://en.wikipedia.org/wiki/Thompson_shell
In the kernel’s process structure. See NOTES - https://man7.org/linux/man-pages/man2/chdir.2.html
Unix defines a Working Directory that every process has, changed with chdir(2): https://man7.org/linux/man-pages/man2/chdir.2.html
This doesn't technically answer the question: POSIX doesn't concern itself with the kernel interface, only with the libc. Most POSIX systems have a kernel with a syscall interface that mirrors the libc API so that these libc functions are just syscall wrappers, but nothing technically prevents the current working directory to be a purely userspace concept maintained by the libc where all relative paths passed to filesystem functions are translated into absolute paths by the libc function before being passed to the kernel via syscall.
But yes, in the BSDs, Linux and Windows, the kernel has a concept of a current working directory.
Is this getting downvoted only because I referred to POSIX rather than UNIX? I'm more familiar with POSIX, but I'm 99% sure the UNIX standard also doesn't say anything about the kernel interface...
A very timely endeavor indeed https://devblogs.microsoft.com/typescript/typescript-native-...
That's about the Typescript compiler performance, not runtime. And this project doesn't even use Typescript does it?
Very cool. Good use of quickjs, although it would have been cool if it somehow didn’t need a libc and just used the syscall interface. Makes me want to give that a try.
I remember some core Unix utilities reimplemented in Perl, mainly done for Win32 systems back in the day. OFC the performance coudn't compete with the ones written in C, but it was good enough.
You're thinking of the Perl Power Tools:
https://github.com/briandfoy/PerlPowerTools
I guess there are related projects such as busybox which contain a collection of utilities implemented in a single binary. There are others such as toybox, and various alternatives in different languages, or with different licenses to choose from.
Kernighan and Ritchie wept. (Tears of joy at an awesome hack, or tears of sadness at an awesome hack?)
See also this post by the author:
Making a micro Linux distro [for RISC-V]
https://popovicu.com/posts/making-a-micro-linux-distro/
Many comments here seem to miss the point: this is not running the Linux Kernel in JavaScript
This is the Linux Userland reimplemented in JavaScript
[dead]
urgh
strange motivation and implementation. I mean it real. There are many existing open source projects that run Linux on JS.