Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uxn

100r.co

Post reply on HN
Print view View original

61–70 of 102 posts

Re: Uxn

#61

Post by 0xDEAFBEAD »

gavindean90 wrote: post #38
throwawayk7h wrote: post #23

Earlier quoted context omitted.

The idea is that it's a standard and stable runtime environment. 100 years from now we'll still be able to run NES games, but running old windows programs may be nearly impossible. uxn is trying to be like the NES in that regard, but for more general use cases than just games. Write a uxn program once, and it can run anywhere, any time (on any device that can host uxn).

I totally get your point but we are great at running old windows now with dosbox and wine.

Not a problem. You can simply emulate Windows, then emulate Uxn within Windows.

Re: Uxn

#62

Post by pjmlp »

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/Alef_(programming_language)

Re: Uxn

#63

Post by exitb »

627467 wrote: post #59
exitb wrote: post #45

It’s somewhat disappointing that over the years the ecosystem[1] accumulated more emulators than substantial programs. [1] https://github.com/hundredrabbits/awesome-uxn

It's a testament to the quality/function of the existing types of ROMs available to uxn and the community that forms around it? Uxn type initiatives are forward-backward looking: how do I ensure future retro compatibility of software created going forward.

It's probably also an interesting challange to implement an emulator.

I was hoping that Uxn could eventually be a vehicle to get rich, graphical apps onto less popular operating systems, like Plan 9 (which they support). While their 1st-party roms are great, the wave of software never came.

Re: Uxn

#65

Post by dartos »

unnkrsnn wrote: post #46
WD-42 wrote: post #17

Earlier quoted context omitted.

Yea that must be why the original electron authors abandoned it and are now working on an editor in Rust.

Is Github working on a new editor?

Atom (and electron) were personal projects of a GitHub engine GitHub decided to back at some point.

Re: Uxn

#67

Post by mikae1 »

627467 wrote: post #58
mikae1 wrote: post #47

Earlier quoted context omitted.

https://wiki.xxiivv.com/site/oscean.html

I have never seen devine mention where he hosts his website, and haven't come across a uxn web server so I think the answer is "no", it's not hosted on uxn. Would be cool to have a web hoster that follows some of the principles layed out by uxn/100r and see what kind of service would turn out.

Check the edit link in the footer. It's GitHub.

I guess being extremely productive and successfully pushing new and exciting concepts in computing also means you need to adopt a certain level of pragmatism.

But yeah, uxn hosting is a cool idea.

Re: Uxn

#68

Post by v3ss0n »

Cannabat wrote: post #48
unnkrsnn wrote: post #46

Earlier quoted context omitted.

Is Github working on a new editor?

The team who create Atom, Electron and tree sitter are working on zed: https://github.com/zed-industries/zed

Zed is fast at starting up, But incredibly slow at When it involves moving UI - atleast on Linux. You better test first before saying that.

Lets think of it , how many time you restart your app when you start using the app?

Re: Uxn

#69

Post by practal »

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 like both the ideas of 100r and of this rebuttal. I think much of this comes down to a fundamental misunderstanding, namely that code is the level at which we understand something. Rather, when we build software, we build a theory [1]. So what we really need are tools for building theories. That makes it possible then to take high-level abstractions, express something in them, and then reason about how these high-level abstractions can be formulated using low-level abstractions (but abstractions nonetheless). This makes it possible to play with your creation at any level and make software that is both correct and incredibly fast. It is the only scaleable way to achieve negative-cost abstractions. Rust is not much better than C here, as both just fix you to a certain level of abstraction.

[1] https://news.ycombinator.com/item?id=10833278

Re: Uxn

#70

Post by v3ss0n »

WD-42 wrote: post #17
v3ss0n wrote: post #13

Earlier quoted context omitted.

Electron is slow when your code is crappy .

Yea that must be why the original electron authors abandoned it and are now working on an editor in Rust.

They left soon after MS Acquisition .
Post reply on HN