1. 25
  1. 3

    Could someone explain to me why uxn is considered human scale computing when other 8-bit or 16-bit computers and VMs are not? I’m suddenly seeing “human scale” and uxn joined together everywhere and it makes little sense to me as compared to other VM architectures. I might just be out of the loop.

    1. 8

      Human-scale computing is just used here to mean that a single person can understand and maintain that computer, it applies to most 8/16 bit machines, it’s akin to the small/appropriate tech term: https://computingwithinlimits.org/2021/papers/limits21-devalk.pdf

      1. 2

        This certainly makes some more sense though I still can’t seem to find a strong definition for any of the choices that folks talk about “human scale computing” in this doc. No energy lifecycle analysis, no actual analysis of what chips are available for salvage, no documentation on the actual salvage process, or the energy usage of the salvage process. I’m also confused on what seem like cross-aims, if we wish to actually reduce our energy footprint through these techniques then folks need to actually use these technologies, but the purpose for these techniques is to have no actual use, so how does that square up?

        Anyway confusing in all, and like @snej I find this a bit too much like Left-Urbit for my liking.

        1. 5

          Wait, I might be a bit confused with how the threads work, and what you’re replying to here.

          Human-scale, or small-tech(or watever the heck), doesn’t correlate to lowering the energy usage. It just means that a single person can understand the stack. I dunno about the rest of what you’re asking

      2. 3

        What does “human scale computing” mean? Based on this page it sounds like an avant-garde manifesto or hand-wavey unimplementable AI-futurist dream, rather than an actual goal.

        I mean, what is one supposed to make of

        Teach the [computing] system what you value, what you believe to be facts, and the models that you use to assess new inputs – nothing more, and nothing less … All the concepts in your language / All your models of the world / Your value system and motivations

        Strong AI? Beat poetry? Schizophrenia? Regardless, it’s certainly not feasible on an 8-bit CPU with 64KB of memory…

        1. 6

          It’s much easier for a single human to fully understand what’s happening (on every level) on an 8-bit system with 64KB of memory. By contrast for example it’s hardly possible to even fully understand a single webpage these days, much less the full stack.

          Also, you can ask what something means without being unkind.

          1. 4

            I do think that was harsh, and I certainly didn’t mean it that way myself. That said, digging into uxn, there’s a lot of charged language on the About page of the wiki containing uxn. Not once either, but throughout. Here’s a few choice phrases:

            Each part of this project should aim to persist across Technological Long Term, not one part of it should rely on heavy dependencies. — Every function should be specific, unobfuscated, and each one carefully chosen against general-purpose libraries, frameworks or wasteful foreign entities.

            Only through open sources, open standards, human-readable formats and their independencies, might they survive this fleeting age of self-destructing informatics

            These attributes should not only be perceptible in its design, but deeply rooted in its code.

            Emphasis mine.

            I think it’s natural to see miffed feelings in the face of something like this. People don’t enjoy proselytizing, whether it’s religion or values, and it’s understandable that being proselytized to will make someone defensive. Nobody enjoys a pushy Jehova’s Witness. Certainly reading that about page left a funny taste in my mouth.

            1. 7

              I think the charged language is part of the point. Projects like uxn deliberately eschew the status quo. From the main page:

              As it stands today, modern software is built with extreme short-sightedness, designed to be run on disposable electronics and near impossible to maintain, so we decided to not participate in this race to the bottom. Our aim is to create a machine that focuses on answering the handful of tasks we need, which is centered around building playful audio/visual experiences.

              I think the context is pretty important to understanding the rest of it. You can see for example how a VM that can be ported to new hardware in a weekend can be seen as something that survives long term for instance.

              I understand the reaction though because something like uxn is both foreign and opposed to nearly everything we do as professional software engineers at $corp. But if we’re having trouble understanding a philosophy that claims we are short sighted, I think we should take a step back and consider that maybe they see something that we don’t.

              1. 3

                Building toys is fine. But they’re not superior to the big stuff. I can empathize with people’s frustration at how big and complex computers and software has gotten, and I definitely enjoy playing with small things as a respite (hey, so far this year I’ve built a little FORTH interpreter and a little b-tree storage engine.)

                Big stuff is big for a reason: it’s trying to solve complex problems, not the least of which is being useable by ordinary humans without CS degrees. And it’s “disposable” for a reason: the state of the art keeps advancing and making more powerful things possible.

                I’ve argued against the “post-collapse computing” dream before. The problem with it is that all the layers of abstraction fall down: what good is a little 8-bit CPU when we don’t have the tech to build the ICs to implement it, or to grow the 99.99999% pure silicon crystals to build the ICs on?

                1. 10

                  Uxn is designed explicitly for salvaged hardware, to be easy to implement on already existing hardware - that only holds as long as there is existing hardware. That’s why most of Uxn’s dev is targetting the NDS, GBA, 286 - and other relatively dead platforms.

                  Building new silicon for it goes against its entire premise.

                  1. 4

                    I’m not trying to sell you on it, just explaining the concept behind it. The authors seem to be happy with it.

                    1. 3

                      This isn’t a competition, nor is any argument necessary. uxn doesn’t claim to be “superior” to anything, and you’re turning an interesting subject into an argument when it was never intended to be. Condescension also doesn’t further the conversation (“Building toys is fine”). You’ve brought nothing but negativity and naysaying to this entire discussion. “it’s certainly not feasible on an 8-bit CPU with 64KB of memory” … Please think about what you’re saying and how it will be received before you post it.

                      1. 3

                        Agreed. I’m probably tracking in some negativity from recent real-life stuff. I apologize.

                        1. 1

                          Fair enough, I don’t mean to make you feel bad. I really appreciate the acknowledgement/apology. Cheers :)

                      2. 2

                        Not to mention the power to make them run…

                  2. 3
                    • By “human” I think you mean “skilled programmer.” Understanding this system requires some advanced concepts.
                    • I think an average human would have a much easier time fully understanding BASIC, in its microcomputer form. I learned computing in the 1970s on microcomputer BASIC and felt I knew that world inside and out by high school. I was never able to really get to grips with the 6502 underneath it because its programming model was so cramped. I never felt comfortable with assembly until the 68000.
                    • “On every level” is a slippery concept. Maybe I didn’t understand my Apple II BASIC on every level without learning its machine code. But the levels don’t stop there. How many 6502 programmers understand the CPU’s hardware? Can you understand uxn without knowing its C interpreter? Or the machine code that interpreter compiles to? Or the tool chain that built it and the modern OS it runs on?
                    • I apologize for being unkind about that web page … I was reeling from an overload of WTF.
                    1. 2

                      By “human” I think you mean “skilled programmer.” Understanding this system requires some advanced concepts.

                      Sure, that’s who we’re talking about.

                      I think an average human would have a much easier time fully understanding BASIC, in its microcomputer form.

                      Maybe, if that’s what works for some people to take control over their computing environments that’s cool too.

                      “On every level” is a slippery concept.

                      I think we’re getting a little in the weeds here. Suffice to say, understanding and reimplementing the uxn stack is certainly easier than doing the same for electron over $os, or GTK, etc.

                      I apologize for being unkind about that web page

                      No problem, all good here.

                      1. 1

                        Nailing down these definitions is exactly what I’m finding puzzling about uxn as a whole. I’m trying to understand where it fits into the picture of things, what motivates its design decisions, but all I’m seeing is vague ideological language. 🤷

                        1. 3

                          Interesting, I had no problem grasping its motivations from reading the webpage (https://100r.co/site/uxn.html). Perhaps what’s lacking is the right context in which it all makes sense?

                          1. 5

                            It totally might be. Like don’t get me wrong, I enjoy working with systems that speak to the some form of mechanical sympathy with the underlying execution model of the code, and I always found stack machines to be very cool for that reason. I suspect a lot of folks enjoy playing around with Lisp Machine architectures for similar reasons.

                            But a lot of the decisions made for uxn feel either unmotivated or motivated by something I don’t understand. Because, there are concepts like branch predictors that seem to be out of the scope of “human-scale computing” that I find honestly really easy to implement (I mean I implemented toy branch predictors in both a VM and VHDL back in college several times, and continue to hack around with branch predictors out of fun now for years.) It’s hard for me to see why a particular design decision has been. And this is a fairly fertile space now with multiple folks working on a sort of “clean fundamental of computing” (projects like Mu or RetroForth). These other projects do a much better job in explaining their unique set of technical tradeoffs in technical ways. The equivalent I see here in uxn feels very hand-wavey, often leaving nothing to compare or little basis of comparison at all.

                            1. 7

                              Uxn’s design was mostly advised by how much work adding a feature would be to the implementer, it’s not as fast as it could be, it’s not even as energy efficient as it could be(despite our working off solar power). Each feature was weighted against the relative complexity it would add for someone else to implement it in software.

                              We tried every other VM we could find before building Uxn, we wanted some features of Nga, some features of the J1, some of the 6502. And also DIV/MUL because we’re fancy like that. The result was Uxn, it’s capable of hosting each of our little work tools, not much more, it won’t do AI, it will never run Chrome, and it would be terrible at mining Bitcoin. It sucks at doing most modern computing, but it’s also sort of the point.

                          2. 2

                            Reminds me slightly of Urb*t in that way, of course minus the alt-right connections.

                  3. 3

                    uxn is somewhat similar in spirit with mu [0], and it is also related to things like callapseos except less scary, and more user friendly (implemented with C, familiar ASM syntax). I gather those project inside the wanna-be humorous name of “fantasy consoles” which includes pico8 or pyxel. Whether the term “fantasy” is appropriate is part of the joke.

                    [0] Worth a glimpse, at least over the introduction and conclusion http://akkartik.name/akkartik-convivial-20200607.pdf