Uxn • Hacker News Board

Re: Uxn

#91

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

kragen wrote: post #89

nine_k wrote: post #86

Earlier quoted context omitted.

> 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.

Fair! These guys run Quake on an Arduino Nano [1], with only 274 kiB of RAM. But they have to jump through a lot of hoops.

Running e.g. Emacs the same way is likely unrealistic, and I find Emacs a great example of software that the user can actually inspect and personalize. I would like most user-facing software tools be like that. (In an ideal world I'd love my personal machine to have a terabyte of Optane memory, but currently such hardware is but a fantasy.)

[1]: https://community.silabs.com/s/share/a5UVm000000Vi1ZMAS/quak...

Re: Uxn

#92

Post by tlavoie » Sat, Oct 12, 2024, 2:00 AM UTC

phoe-krk wrote: post #14

dang wrote: post #4

Related. Others? Tal is the programming language for the Uxn virtual machine (2021) - https://news.ycombinator.com/item?id=39575102 - March 2024 (18 comments) Virtualizing Uxn - https://news.ycombinator.com/item?id=37091091 - Aug 2023 (4 comments) The Uxn Ecosystem - https://news.ycombinator.com/item?id=36734445 - July 2023 (54 comments) The Uxn Ecosystem - https://news.ycombinator.com/item?id=36642390 - July 2023 (2…

I don't want to go to Chel-C - https://news.ycombinator.com/item?id=31705239 - June 2022 (124 comments) is sorta-related, since it's a rebuttal.

I see that one of the issues given with uxn is that it isn't efficient, nor self-hosting. I wonder how they'd feel about something like MirageOS, where OCaml is used to create unikernels that contain just what is needed. The application can be developed as a regular program while on Linux, before being deployed at least as a VM image. (Not sure about bare-metal)

Re: Uxn

#93

Post by theamk » Sat, Oct 12, 2024, 2:38 AM UTC

bshanks wrote: post #81

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.…

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 sha…

Interesting comment, thanks for finding it!

I have a raspberry pi 2 (one of the first one, very low) and tried compiling orca.c on it with gcc. It took 7 seconds and produced 38KB executable. This is more than what I expected, but it's still pretty reasonable. However, I can see how this can be annoying with very rapid iteration cycles.

(Btw, building alone (no linking) takes 5.4 sec, so compilation time dominates. And optimized build (-O3) was over a minute. Not something to be done as part of development.)

But then I remembered about lighter compilers, and tried 'tcc'. This was substantially faster - just 0.6 seconds for the whole process! I think this is very reasonable, and for newer Pi's it would be even faster.

Also note that my idea was to forgo standard libraries and only link to libuxn (and only include uxn.h). This theoretical libuxn will have the same role as UXN virtual machine - written only once, and then frozen in stone, with no updates. This will take care of large binary sizes - if you are only linking to libuxn there are no updates to download. And there is no need to lookup documentation or consult stack overflow, as you are only allowed to link to libuxn, no third-party libraries.

Will such limited environment be inconvenient? Somewhat, but less that full-blown VM. Will it take effort to write and maintain libuxn on all platforms? Yes, but less effort than full-blown VM. Won't libuxn have some bugs requiring updates? Likely, but I bet it will have fewer bugs than full-blown VM.

As for other things (updating binary over internet, shareing

Re: Uxn

#94

Post by theamk » Sat, Oct 12, 2024, 2:44 AM 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.

Simple C code from 1990 still works, as long as it does not depend on non-standard libraries.

Imagine how cool it would be if old games were distributed in source code form, so that anyone can modify and "remix" it as much as they want with a simple text editor?

This was impossible back in 1990s, but today we can get a C compiler (tcc) which takes less than 1 megabyte of space and compiles+links a game in less than a second. As long as you don't depend on too many third-party libraries, you can ship C code, compile the game on each start and user won't even notice!

Re: Uxn

#95

Post by anthk » Sat, Oct 12, 2024, 7:38 AM 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…

9front/plan9 users don't forget it, they are using it in spirit with the Nc compilers, where N=arch.

On memory management, well, it always sucks, but plan9's C+lib9 it's far smaller than C99+POSIX and you have less things to worry about.

Also: https://github.com/anton2920/alef-plan9

Re: Uxn

#96

Post by anthk » Sat, Oct 12, 2024, 7:49 AM UTC

hosh wrote: post #80

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.…

There's an effort to port uxn to DuskOS ( https://duskos.org/ ). The goal here isn't to be maximally performant or memory efficient (though at this point, running uxn on DuskOS on certain architecture is faster than the mainline uxn implementation). Rather, these are computing platforms to maximize usefulness in the event of a societal collapse. That is why there is a handbook of uxn opscode made to include hand gest…

Dusks OS badly needs a ZMachine interpreter. The number of software running on DuskOS would skyrocket. From a Tetris implementation to tons of libre IF (and games) such as SpiritWrak, All Thing Devours, Reversi, ...

https://jxself.org/git/

Re: Uxn

#97

Post by pjmlp » Sat, Oct 12, 2024, 7:53 AM UTC

ruslan wrote: post #90

pjmlp wrote: post #62

Earlier quoted context omitted.

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 wor…

Inferno still has C user space, check source code made available by Vita Nuova.

Like on Android it is as support for Limbo libraries and DisVM, and drivers.

Android Treble also allows for drivers to be written in Java, and ART does JIT/AOT.

Re: Uxn

#98

Post by pjmlp » Sat, Oct 12, 2024, 7:57 AM UTC

anthk wrote: post #95

pjmlp wrote: post #62

Earlier quoted context omitted.

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…

9front/plan9 users don't forget it, they are using it in spirit with the Nc compilers, where N=arch. On memory management, well, it always sucks, but plan9's C+lib9 it's far smaller than C99+POSIX and you have less things to worry about. Also: https://github.com/anton2920/alef-plan9

They forget because Inferno isn't Plan 9, rather its successor, with several learnings taken into account.

Re: Uxn

#99

Post by theamk » Sat, Oct 12, 2024, 9:44 PM UTC

hosh wrote: post #80

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.…

There's an effort to port uxn to DuskOS ( https://duskos.org/ ). The goal here isn't to be maximally performant or memory efficient (though at this point, running uxn on DuskOS on certain architecture is faster than the mainline uxn implementation). Rather, these are computing platforms to maximize usefulness in the event of a societal collapse. That is why there is a handbook of uxn opscode made to include hand gest…

I don't get it.. DuskOS mentions "it runs plenty fast on an old Pentium 75 MHz with 16mb of RAM." - that's a lot! I'd expect something geared for "civilization collapse" to be compatible with smaller embedded micros, like 80 KB RAM of esp8266 and 500 KB of RAM of ESP32.

I remember programming on 286 and 386 machines with 33 Mhz and 2-4 MB of RAM, and it was perfectly usable with Pascal and even C (although C was annoyingly slow, a few seconds per build). If your idea of old machine is Pentium with a _whole megabyte_ of RAM, or even more (gasp!), you don't need to pay Forth penalty, you can have normal languages with good ergonomics.

Re: Uxn

#100

Post by hosh » Sun, Oct 13, 2024, 11:05 AM UTC

theamk wrote: post #99

hosh wrote: post #80

Earlier quoted context omitted.

There's an effort to port uxn to DuskOS ( https://duskos.org/ ). The goal here isn't to be maximally performant or memory efficient (though at this point, running uxn on DuskOS on certain architecture is faster than the mainline uxn implementation). Rather, these are computing platforms to maximize usefulness in the event of a societal collapse. That is why there is a handbook of uxn opscode made to include hand gest…

I don't get it.. DuskOS mentions "it runs plenty fast on an old Pentium 75 MHz with 16mb of RAM." - that's a lot! I'd expect something geared for "civilization collapse" to be compatible with smaller embedded micros, like 80 KB RAM of esp8266 and 500 KB of RAM of ESP32. I remember programming on 286 and 386 machines with 33 Mhz and 2-4 MB of RAM, and it was perfectly usable with Pascal and even C (although C was anno…

The smaller embedded micros are the target of CollapseOS, which is folded into DuskOS. The stage DuskOS is targeting is when we stop being able to have the ability to make new computers and new chips, and we start looking to salvage old ones laying around. There is also recovering knowledge from disks.