Uxn • Hacker News Board

Re: Uxn

#81

Post by bshanks » Fri, Oct 11, 2024, 6:19 PM UTC

theamk wrote: post #72

__MatrixMan__ wrote: post #5

That page answers "what?" I had to browse around a bit to answer "why?" I landed here: https://100r.co/site/mission.html It's a cool idea. I found the contrast with electron helpful: > While solving some of our issues, Electron was rapidly increasing in size and hunger, so despite it being open-source soon joined the rest of the software that we did away with. Our focus shifted toward reducing our energy use, and to…

It's interesting that the virtual machine is neither very fast nor it is memory efficient. If you really want to have max speed + portability, it's hard to beat restricted subset of C, especially since almost every platform has highly optimized compiler. Something like: "Code must conform to C89 with -nostdlib, and can only link to libuxn (that we wrote). And use uxn_main() instead of main(), as libuxn defines main.…

One of the authors talks about using C with SDL or libdraw here: https://news.ycombinator.com/item?id=31715080

Since they were on a boat with a Raspberry Pi and not much battery power or internet, in addition to execution speed and portability, they were probably also concerned with:

- speed of compilation and linking (on small machines like Raspberry Pi)

- binary size of anything that might have to be updated or shared over the internet

- having to troubleshooting emergent issues without the ability to lookup documentation or download updates or tools from the internet

In this situation, a simpler language on a simpler VM is probably going to be faster to develop with than compiling/linking a subset of C, and after the initial implementation of the VM, might present less opportunity for an unintended interaction of leaky abstractions in your libuxn and your toolchain to ruin your day on a day when you don't have internet connectivity to check Stackoverflow or to update some buggy dependency.

Re: Uxn

#82

Post by bshanks » Fri, Oct 11, 2024, 6:31 PM UTC

__MatrixMan__ wrote: post #5

That page answers "what?" I had to browse around a bit to answer "why?" I landed here: https://100r.co/site/mission.html It's a cool idea. I found the contrast with electron helpful: > While solving some of our issues, Electron was rapidly increasing in size and hunger, so despite it being open-source soon joined the rest of the software that we did away with. Our focus shifted toward reducing our energy use, and to…

I also found https://git.sr.ht/~rabbits/libreplanet2022/tree/master/item/... to understand the context

Re: Uxn

#83

Post by kragen » Fri, Oct 11, 2024, 7:22 PM UTC

627467 wrote: post #57

kragen wrote: post #42

Earlier quoted context omitted.

For now, but maintaining DOSBox and especially WINE continues to require substantial engineering effort, in part because the platforms they're running on change. Implementing Uxn/Varvara is many orders of magnitude easier than implementing Win32, as evidenced by the fact that many more people have done it despite the much smaller base of applications they can then run. It seems likely that many Win32 applications wil…

I understand the argument, and feel good about it. I too would rather our software was made with simplicity and performance in mind not only following the premise that hw resources will only increase so let's ignore those constrains today. But another perspective for win32 support in future metal is the bigger "community" (users, software, etc) so the increase in support complexity is compensated for much (much) larg…

It might work out that way, or it might not. The current open-source community is very much a product of current social conditions, and those conditions might change. They've changed before, and could change again.

Things like LLMs and the xz backdoor, for example, may make it unappealing to accept code from people you don't know personally; things like Apple's notarization requirements may make it impractical to run open-source software except as part of a proprietary package; software patents or legal liability for third parties using your software could make it legally unappealing to free your code; etc.

Re: Uxn

#84

Post by kragen » Fri, Oct 11, 2024, 7:55 PM UTC

vessenes wrote: post #55

kragen wrote: post #41

Earlier quoted context omitted.

It seems a bit off target, though. It's not entirely wrong; it's true, for example, that Uxn doesn't lend itself to writing an efficient implementation easily. It's also true that the existing implementations are all on hardware that still requires a substantial amount of power, 2000 milliwatts or more, as well as being fairly inefficient in absolute terms. On the other hand, on my laptop, the Left text editor runnin…

To be clear, I don't have any interest in shitting on a hobby of any sort, be it low-energy computing or whatever. I do lots of stuff that's completely for the joy of it, and has no logical benefits. That said, I think he's exactly right. This ESP32 runs linux, and can run vi: https://www.mouser.com/ProductDetail/Espressif-Systems/ESP32... . Its datasheet says the power supply is 3V at 0.5amps. It can probably run em…

Having written a sort of Forth compiler without immediate myself, I agree that uxntal is not very Forthlike. I like Golang, JS, and Forth.

Your link is broken, but https://hackaday.com/2021/07/21/its-linux-but-on-an-esp32/ documents someone getting Linux running on an ESP32-S3 under a software emulation of RISC-V with an MMU. That's not obviously more efficient than a simple Uxn emulator and seems likely to be worse. People have also gotten ucLinux running directly on ESP32-S3 with uclibc, which seems unlikely to be able to run Emacs or GCC, though not, as you say, because the CPU is too slow or the RAM is too small. I'm not sure I've run Emacs on a machine with less than 16MiB of RAM but I'm sure it's possible.

1500 milliwatts is still several orders of magnitude more power than I think a personal computer needs, and 16MiB is obviously a couple of orders of magnitude more RAM.

Emacs is actually surprisingly efficient. We remember it as being slow and bulky in part because 30 years ago it was among the bigger resource draws on the machines we used at the time and in part because it actually was slower then. Current Emacs compiles elisp to machine code.

It turns out that it's actually pretty common for a hobbyist to be able to beat tens to hundreds of thousands of man years going into optimizing compilers, as you know if you follow the demoscene at all. Proebsting's Law explains why. The silicon design and production are equally at the disposal of GCC and the hobbyist. But the current applications codebase can easily consume all that surplus computational power.

I agree that if you were to rewrite your applications in sane-to-simple C code, compiled with a good compiler, it would come out faster than Uxn, though only by about 10×. But nobody has done it. Vaporware always beats shipped code because vaporware doesn't have bugs or scope/schedule tradeoffs.

I think it's possible to do much better than Uxn. But I also am not convinced that anybody has.

Re: Uxn

#85

Post by nine_k » Fri, Oct 11, 2024, 8:25 PM UTC

0xdeadbeefbabe wrote: post #75

theamk wrote: post #72

Earlier quoted context omitted.

It's interesting that the virtual machine is neither very fast nor it is memory efficient. If you really want to have max speed + portability, it's hard to beat restricted subset of C, especially since almost every platform has highly optimized compiler. Something like: "Code must conform to C89 with -nostdlib, and can only link to libuxn (that we wrote). And use uxn_main() instead of main(), as libuxn defines main.…

Infocom also took the VM approach and I can still play their games years later, and it worked out for them in the short term too.

Infocom's games require little CPU by their nature, and most of the memory is spent on graphics.

Re: Uxn

#86

Post by nine_k » Fri, Oct 11, 2024, 8:40 PM UTC

kragen wrote: post #84

vessenes wrote: post #55

Earlier quoted context omitted.

To be clear, I don't have any interest in shitting on a hobby of any sort, be it low-energy computing or whatever. I do lots of stuff that's completely for the joy of it, and has no logical benefits. That said, I think he's exactly right. This ESP32 runs linux, and can run vi: https://www.mouser.com/ProductDetail/Espressif-Systems/ESP32... . Its datasheet says the power supply is 3V at 0.5amps. It can probably run em…

Having written a sort of Forth compiler without immediate myself, I agree that uxntal is not very Forthlike. I like Golang, JS, and Forth. Your link is broken, but https://hackaday.com/2021/07/21/its-linux-but-on-an-esp32/ documents someone getting Linux running on an ESP32-S3 under a software emulation of RISC-V with an MMU. That's not obviously more efficient than a simple Uxn emulator and seems likely to be worse.…

> 1500 milliwatts is still several orders of magnitude more power than I think a personal computer needs, and 16MiB is obviously a couple of orders of magnitude more RAM.

So, your idea is a computer with less than 200 kiB of RAM? So, devices like a PC AT 286 or Amiga A2000, with their whole 1 MiB RAM, are hopelessly overpowered, and the right kind of a machine is something like a Sinclair Spectrum?

Re: Uxn

#87

Post by Narishma » Fri, Oct 11, 2024, 8:55 PM UTC

d0mine wrote: post #76

__MatrixMan__ wrote: post #5

That page answers "what?" I had to browse around a bit to answer "why?" I landed here: https://100r.co/site/mission.html It's a cool idea. I found the contrast with electron helpful: > While solving some of our issues, Electron was rapidly increasing in size and hunger, so despite it being open-source soon joined the rest of the software that we did away with. Our focus shifted toward reducing our energy use, and to…

The mission sounds like the original Java mission. Unclear why something like zig/llvm won't fit the bill.

Don'y know about zig but LLVM is heavy and complex.

Re: Uxn

#88

Post by dmwilcox » Fri, Oct 11, 2024, 9:00 PM UTC

I love this stuff. Thinking about how our software and its supply chain break down so dramatically given small adversaries like 'intermittent internet access' or 'old crappy machines' has definitely changed the way I think about software as a developer.

I appreciate the care 100r has put into working with their doors open and sharing their lives, circumstances and worldview.

I'm not using Uxn but am I following a bit of a quest to try my hand at personal shaped computing. I didn't really want to write an emulator (I don't have a game-preservation shaped problem) and I like to be able to just "takeover" computers around me with bootable USB sticks. Fittingly, my project is in x86 assembly, real-mode with BIOS routines for IO and as a stand-in for drivers. (Tldr; not amazing but serviceable, and Devine is right that 64kb is a lot)

As a long time python programmer, I've found it fun to play in the land of understanding memory layouts, segmentation, and writing assembler. I highly recommend it for educational purposes. I don't need a hobby project that looks like work in my off time so real-mode programming fits nicely. As a plus I rediscovered MSDOS .COM files and it's shockingly fast and will give you 64kb of memory setup and a filesystem which is handy. Again here I don't have to write an emulator and my little Forth-like project could bootstrap from DOS assemblers and tool chains.

My take away from Uxn project is "go ahead and try to do something fun with a computer". Uxn very much isn't about making the most efficient p-machine or best language, but something that fits 100r. And that more of us with the background in computers ought to try something off the beaten path because we might learn something and we might have fun doing it.

Re: Uxn

#89

Post by kragen » Fri, Oct 11, 2024, 9:23 PM UTC

nine_k wrote: post #86

kragen wrote: post #84

Earlier quoted context omitted.

Having written a sort of Forth compiler without immediate myself, I agree that uxntal is not very Forthlike. I like Golang, JS, and Forth. Your link is broken, but https://hackaday.com/2021/07/21/its-linux-but-on-an-esp32/ documents someone getting Linux running on an ESP32-S3 under a software emulation of RISC-V with an MMU. That's not obviously more efficient than a simple Uxn emulator and seems likely to be worse.…

> 1500 milliwatts is still several orders of magnitude more power than I think a personal computer needs, and 16MiB is obviously a couple of orders of magnitude more RAM. So, your idea is a computer with less than 200 kiB of RAM? So, devices like a PC AT 286 or Amiga A2000, with their whole 1 MiB RAM, are hopelessly overpowered, and the right kind of a machine is something like a Sinclair Spectrum?

An adequate kind, not "the right kind". Flash is a lot faster than electromechanical disks, so you can get by with less RAM.

Re: Uxn

#90

Post by ruslan » Fri, Oct 11, 2024, 9:43 PM UTC

pjmlp wrote: post #62

ruslan wrote: post #27

This Uxn thing reminds me Inferno[1] - a VM based operating system from Bell Labs with its own programming language, GUI and networking protocol. It can run on may hardware with just 1 MB of RAM. But Inferno is far more than that, it's a Plan9's descendant. 1. https://en.wikipedia.org/wiki/Inferno_(operating_system)

In modern times the closest we have to Inferno is Android, which traces back to Bell Labs original goal to target Inferno against Sun's Java efforts on the market. Pity that most Plan 9 afficionados usually always forget about Inferno, with Limbo being the re-consideration that dropping Alef from Plan 9, or designing it without automatic memory management in first place was a mistake. https://en.wikipedia.org/wiki/Al…

> In modern times the closest we have to Inferno is Android, which traces back to Bell Labs original goal to target Inferno against Sun's Java efforts on the market.

That's interesting, I never looked on Android at that angle. Still, Android is based on Linux (Unix), it allows JIT and NDK. Whereas Inferno does not allow escape from VM conceptually, and the whole OS, except low-level stuff, is written in Limbo and works totally in VM.

I once tried Inferno somewhere in 1998 on my PC, played with it a litte and removed. But three years later I met it in Lucent/Definity Avaya PSTN switches the company I worked for bought. Not to say I was surprised. :-)