6 ms·

A quick glance shows it uses GNU Make but that's only a build time dependency, I guess.

by ape4 3y ago

yjftsjthsd-h 3y ago
All software needs dependencies at build time, saying no dependencies always means runtime.
- blueflow 3y ago
  I'm surprised the Kernel doesn't count here.
  - yjftsjthsd-h 3y ago
    At that point we really get into semantics... But now that you mention it, I would be interested to see if it could be built with APE to benefit from their bare metal support.
  - rollcat 3y ago
    It does. Writing your software to directly use the syscalls of a specific kernel does not make it "zero dependency", it makes it "one dependency" - and non-portable. The author elaborates on their rationale and the technical details in a blog post: <https://www.matheusmoreira.com/articles/linux-system-calls https://www.matheusmoreira.com/articles/linux-system-calls> TBH I have mixed feelings about this approach. It's true that this is more or less what Go or (Cosmopolitan libc) do, but the motivation in their case is to maximize portability (by making cross-compilation trivial). However when you #include <linux/...>, you not only make your software non-portable, you also make it a PITA to cross-compile as you need the kernel headers on the host machine. In contrast, with Go or cosmo, I can trivially build a tiny /sbin/init for amd64 Linux, pack it up with cpio, and run it with qemu-system-x86_64 -initrd - all from a Mac/arm64 host.
    - craftkiller 3y ago
      Surely its more than one dependency. For example, you'll need a processor. Not just any processor, but a processor for which a C compiler has been written.
      - matheusmoreira 3y ago
        That's a great question... I wonder if Justine would be interested in that. She has her own sector lisp too.
      - yawpitch 3y ago
        For that matter you’ll need a universe, the physics of which must allow both semiconductive metals and the eventual evolution of multicellular biochemistry.
      - rollcat 3y ago
        Like sibling comment points out, the CPU and the rest of the universe can be considered indirect dependencies. Once you have everything you need to boot the Linux kernel (e.g. laws of physics, paid the power bill...), you're good to go ;)
    - matheusmoreira 3y ago
      > However when you #include <linux/...>, you not only make your software non-portable, you also make it a PITA to cross-compile as you need the kernel headers on the host machine. Yes, that is certainly a problem that I need to solve. I added some support for cross compilation in the makefile. It currently requires clang for that. ifdef TARGET ifndef UAPI $(error UAPI must be defined when cross compiling) endif TARGET.triple := $(TARGET)-unknown-linux-elf override CC := clang -target $(TARGET.triple) else TARGET := $(shell uname -m) endif With this, I was able to cross compile lone for x86_64 from within the Termux environment of my aarch64 smartphone. All I had to do was obtain the Linux user space API headers for x86_64. Getting those headers was somewhat annoying but doable, there are packages for them in many Linux distributions. I made a Termux package request for multiplatform Linux UAPI headers specifically so I could cross compile lone but unfortunately it was rejected. https://github.com/termux/termux-packages/issues/16069 https://github.com/termux/termux-packages/issues/16069
matheusmoreira 3y ago
Yes. It has zero runtime dependencies but development currently assumes GNU tools. The test suite for example is entirely written in bash and uses GNU coreutils. I submitted a patch to coreutils to allow env to set argv[0] of programs specifically so I could use it in my test suite. Currently lone is a single C source file. It could easily be compiled manually if necessary. I've started reorganizing the repository though so that's likely to change.
- nvy 3y ago
  >Currently lone is a single C source file. Is there a plan to write a lone compiler so as to eventually have lone bootstrapping/compiling itself so that you no longer have to sully your hands with C?
  - shrimp_emoji 3y ago
    You don't have to; you get to! ;D
    - nvy 3y ago
      Hey some people like debasing themselves with C; I'm not gonna kink-shame.
  - matheusmoreira 3y ago
    I would like that. I wanted to create the simplest possible reference C implementation first so the language can always be bootstrapped with a C compiler. After that, I'll probably make a better one. I'm considering a Rust implementation as well. At least that's what I tell myself. Just this simple interpreter has already generated a lifetime of work. It's making me wish I had infinite time to work on it.

A quick glance shows it uses GNU Make but that's only a build time dependency, I guess.

by ape4 3y ago

A quick glance shows it uses GNU Make but that's only a build time dependency, I guess.

yjftsjthsd-h 3y ago

All software needs dependencies at build time, saying no dependencies always means runtime.

blueflow 3y ago
I'm surprised the Kernel doesn't count here.
- yjftsjthsd-h 3y ago
  At that point we really get into semantics... But now that you mention it, I would be interested to see if it could be built with APE to benefit from their bare metal support.
- rollcat 3y ago
  It does. Writing your software to directly use the syscalls of a specific kernel does not make it "zero dependency", it makes it "one dependency" - and non-portable. The author elaborates on their rationale and the technical details in a blog post: <https://www.matheusmoreira.com/articles/linux-system-calls https://www.matheusmoreira.com/articles/linux-system-calls> TBH I have mixed feelings about this approach. It's true that this is more or less what Go or (Cosmopolitan libc) do, but the motivation in their case is to maximize portability (by making cross-compilation trivial). However when you #include <linux/...>, you not only make your software non-portable, you also make it a PITA to cross-compile as you need the kernel headers on the host machine. In contrast, with Go or cosmo, I can trivially build a tiny /sbin/init for amd64 Linux, pack it up with cpio, and run it with qemu-system-x86_64 -initrd - all from a Mac/arm64 host.
  - craftkiller 3y ago
    Surely its more than one dependency. For example, you'll need a processor. Not just any processor, but a processor for which a C compiler has been written.
    - matheusmoreira 3y ago
      That's a great question... I wonder if Justine would be interested in that. She has her own sector lisp too.
    - yawpitch 3y ago
      For that matter you’ll need a universe, the physics of which must allow both semiconductive metals and the eventual evolution of multicellular biochemistry.
    - rollcat 3y ago
      Like sibling comment points out, the CPU and the rest of the universe can be considered indirect dependencies. Once you have everything you need to boot the Linux kernel (e.g. laws of physics, paid the power bill...), you're good to go ;)
  - matheusmoreira 3y ago
    > However when you #include <linux/...>, you not only make your software non-portable, you also make it a PITA to cross-compile as you need the kernel headers on the host machine. Yes, that is certainly a problem that I need to solve. I added some support for cross compilation in the makefile. It currently requires clang for that. ifdef TARGET ifndef UAPI $(error UAPI must be defined when cross compiling) endif TARGET.triple := $(TARGET)-unknown-linux-elf override CC := clang -target $(TARGET.triple) else TARGET := $(shell uname -m) endif With this, I was able to cross compile lone for x86_64 from within the Termux environment of my aarch64 smartphone. All I had to do was obtain the Linux user space API headers for x86_64. Getting those headers was somewhat annoying but doable, there are packages for them in many Linux distributions. I made a Termux package request for multiplatform Linux UAPI headers specifically so I could cross compile lone but unfortunately it was rejected. https://github.com/termux/termux-packages/issues/16069 https://github.com/termux/termux-packages/issues/16069

matheusmoreira 3y ago

Yes. It has zero runtime dependencies but development currently assumes GNU tools. The test suite for example is entirely written in bash and uses GNU coreutils. I submitted a patch to coreutils to allow env to set argv[0] of programs specifically so I could use it in my test suite. Currently lone is a single C source file. It could easily be compiled manually if necessary. I've started reorganizing the repository though so that's likely to change.

nvy 3y ago
>Currently lone is a single C source file. Is there a plan to write a lone compiler so as to eventually have lone bootstrapping/compiling itself so that you no longer have to sully your hands with C?
- shrimp_emoji 3y ago
  You don't have to; you get to! ;D
  - nvy 3y ago
    Hey some people like debasing themselves with C; I'm not gonna kink-shame.
- matheusmoreira 3y ago
  I would like that. I wanted to create the simplest possible reference C implementation first so the language can always be bootstrapped with a C compiler. After that, I'll probably make a better one. I'm considering a Rust implementation as well. At least that's what I tell myself. Just this simple interpreter has already generated a lifetime of work. It's making me wish I had infinite time to work on it.