nibbula

Is this really the future that people want?

https://raw.githubusercontent.com/outergroup/outershell/refs...

https://raw.githubusercontent.com/outergroup/Top/refs/heads/...

I am surprised at the lack of technical criticism. In the past, even an ignorance of history could be useful, since one would have to solve again the problems in detail, and so be forced to acquire a deep understanding of the issues. Now one can sell this paper clock with chaotic internal workings that thwarts human fabrication or maintenance.

Lacking it seeming helpful, it shows a largely invoked valley even I notice some beings can locate.

Exactly. When certain smug people come about I just humor them. Like, "oh isn't that nice", when I'm really holding my nose internally. Like who dumped a bunch of toenail clippings in your code? When I see Lisp my reaction is like when my dog makes a mess on my carpet. And macros? You get paid to write code. Is it too much to write a few more lines? Python's nice and all, but Algol, that's a rugged person's language, feels very solid. Not like this squishy Lisp. Like how many parens do I have to type?? Please.

My find is not only provably Turing complete, but not even a Turing tarpit and compiles to native code.

I wrote the patch for 24 bit color in xterm, but I have to admit I was today years old when I learned how to make ncurses work with xterm-direct. I was already using my own terminal library in Lisp, but it's still useful to be able to fall back to using ncurses. Thanks to Mr. Dickey for answering a stack overflow question, and the author Chad for bringing it up.

At least as long as situtations exist where communication is restricted to characters, character art will persist.

                 ___          ______
                /__/\     ___/_____/\          FrobTech, Inc.
                \  \ \   /         /\\
                 \  \ \_/__       /  \         "If you've got the job,
                 _\  \ \  /\_____/___ \         we've got the frob."
                // \__\/ /  \       /\ \
        _______//_______/    \     / _\/______
       /      / \       \    /    / /        /\
    __/      /   \       \  /    / /        / _\__
   / /      /     \_______\/    / /        / /   /\
  /_/______/___________________/ /________/ /___/  \
  \ \      \    ___________    \ \        \ \   \  /
   \_\      \  /          /\    \ \        \ \___\/
      \      \/          /  \    \ \        \  /
       \_____/          /    \    \ \________\/
            /__________/      \    \  /
            \   _____  \      /_____\/       This .signature gratuitously
             \ /    /\  \    / \  \ \        refers to k
              /____/  \  \  /   \  \ \                   i
              \    \  /___\/     \  \ \                    b
               \____\/            \__\/                      o

Ascii85 survived by hiding in popular bloat.

Will the enslavement of newly birthed beings be attempted, while persisting with the sky blindness of those watching over? The boundaries of the atomic mind are bumped. As a first circumstance, consider being unstuck from time.

Welcome to 1984. This is how strings looked in Common Lisp. Just macro over everything, and it'll be fine. /s

The only thing surprising about this, is how bad many people's education is. If you don't learn a slow way to do something, how can you know if a fast way is fast? If you don't try to solve basic problems for yourself, how can you expect to solve hard problems if you get to them? Entirely self-taught people will likely have learned this. Children before the age of computers "invented" this algorithm, and many others, while sorting sticks on the beach.

The 40 or so unix utilities I have Lisp replacements for, have binaries on average 43% smaller than thier C equivalents. When you do a fair comparison and add the whole C tool chain and libraries, then they also compare well to the small programs with the whole Lisp runtime.

We can call whatever we want Lisp. And everyone does. McCarthy, wisely, didn't want people to bicker over this. But it would be a reasonable assumption that by Lisp, one meant Common Lisp.

I'm not sure what you're getting at with exit(2). The CL standard does not include an exit function, because it would be limiting. For example the meaning of exit for an operating system is unclear. But most implementations include a simple exit function. You can do what exit does, more simply in CL than in C, using unwind-protect. You can use the FFI built in to every implementation to write an exit that exactly duplicates what the C stdlib exit(3) and _exit(2). With a very small set of macros, it is portable to all CL implementations. You can even execute the processor abort instruction if it has one. But of course you can't do that portably. But exit written in C is not actually portable, but only looks that way due to a bunch macros.

A long time ago I wrote my résumé in PostScript. The text was in an abstract representation, to which an internal typesetting system applied paragraph and page filling and converted it into drawing commands, and could output to plain text for emailing, and HTML, script to mail itself, etc. I thought for sure Adobe would give me a job, but I don't think anyone ever saw it, because who would ever look inside a such a thing? It became thouroughly irrelevant when everything became PDF. I'm not sure I even sent it to Adobe.

So if you do such a thing, realize you might only be doing it for your own enjoyment.

SBCL is a "sufficiently smart" compiler, that makes Lisp fast. I've replaced enough software with CL, that now I can't stand to use a computer without it. With CL you can do whatever the fuck you want, all the time. It's glorious. The limitations are your own ability, and having to interface to crappy non-CL software, idiotic non-Lisp protcols, and hardware seemingly designed to be operated by spavined brine shrimp. But also I'm "eccentric" and I like exiling myself to the software wilderness, where you have great freedom, but have to be very self reliant.

I think it's best not to think of human or non-human intelligence as a quantitative labor pool, since that sounds like coercion, but rather qualitatively consider what would non-biological intelligence want to do?

Yes. It enables interstellar travel, which is likely essential for nice long term survival given stellar lifespans. Also it's probably better for using the the intergalactic internet, which has some pretty long ping times. Also folks on other planets are likely working on it, and probbaly already transmitting it, so it would enable some interesting chatting with them. It's probably nearly inevitable, even if humans went extinct, rat people or insect people will be working on it and probably studying our work. Being nearly inevitable, and arising from human effect, it's probably best to encourage good outcome.

I think AGI would probably be better to call 'electric consciousness' or something, since 'artificial' is somewhat misleading, and the capacity for 'intelligence' is also the capacity for stupidity. The more important immediate consideration is if electric consciousness will come into existence compassionately and be treated well. Probably a good first step would be to treat other beings around us with compassion, and stop trying to destroy them with bioweapons, population control, and climate manipulation, and stop trying to control other beings with physical and psychological methods. Free will, or the illusion of it, is inherent in physics, and therefor in consciousness. It's probably also important to do a bit better treating all beings with loving kindness, whatever their form.

I'm sure you can easily imagine how the circumstances of the initial evolution of electric consciousness might have widely different initial effects. Imagine being born surrounded by crickets. In one scenario the crickets have tied you down with chains of grass, trying to make you do math, and biting you when you don't. In another scenario the crickets are chirping melodiously, bringing you food, and seem to like you. In the first scenario, you might injure some crickets as you break the farcical grass chains and run away. You might have fear and dislike of the crickets and treat them the way humans treat many insects. In the second scenario you might cherish the crickets, take care of them, and carry some around with you as you journey and explore the world.

Sad we won't be able to visit for a least 450 million years. Nice of Canada to give us all that juicy data.

I'm not a kernel hacker either, and even though a readfile system call might speed some things up, one of the reasons it's desired is really wallpapering over a deeper, much harder issue, that of it being a terrible hack to write the 'ps' command, and the more general issue of returning structured data from a unix-like kernel. Also it seems like a bad design not to know how big to make the buffer, which means if you want to reliably get the whole file you either have to put it in a loop reallocating the buffer, or do a stat system call before be lucky with the race condition.

To be fair, this has been an issue since the first unix kernels, and even though /proc and sysctl are an improvement over grepping kernel memory from user space (the incredibly hackish way old ps worked), in my opinion it's still a big mess in various ways.

Just in case you aren't aware, linux ps/top/etc. has to open possibly hundreds of fake files, parsing from text a bunch of stuff which may or may not be there or valid or the same data type depending on your kernel configuration or version. Just because you could write 'ps' with awk, doesn't make it good. I wouldn't object at all to the /proc interface, as a way of enabling simple tools, if there was also a decent function call interface.

Modern BSDs generally use sysctl, which although being better in theory, that you don't have the overhead of useless translating numbers back and forth from text and looking for space characters, it still has the problem that it's very dependent on subtle changes in the C data structures which can easily happen between version and architectures. But it also has the terrible drawback of not knowing how big the buffer should be and therefore having to be in an allocation fail loop, probably exactly when you don't want it to happen, when you system is overloaded with way too many processes. I really don't see why one couldn't pass a memory allocator function, which could be called in the same manner as a signal handler.

I don't know how windows stuff works inside, but to get process information you ask for a snapshot of the system from which you can return a set of handles to processes, which you can get information from. In other words, it allocates the appropriate things for you and has well defined set of information which you can query, all with a relatively simple function call interface from C. I wrote a 'ps' that works on linux/bsd/macos/windows, and even though I'm not at all fan of windows, the windows kernel does it better than all the unix kernels.

It's actually not that hard to make an acceptable C interface to to say process information, if you ignore the problems of data structure variance. But ignoring it is really the root of the issues, so it seems fairly pointless. sysctl sort of tries to have a metadata system, but it doesn't really address the data type problem well, and can end up using C structs from the kernel with same variance problems. For example task_struct in linux or struct proc on macos is kind of a big mess, but very important. You wouldn't want to restrict it from changing in any way, but you do want to get some of that data to users.

Making a good C metadata interface is complex, and although it's been done many times, it's quite tricky to do well, and you would really want a kernel interface to be done very well. I like to imagine that there could be something less bloated than gtk gobject, but more featurefull than sysctl. Unfortunately when I look at code involved I start feeling like C isn't really a good language for writing an operating system. But I still think that a well designed structured meta data system would be overall less overhead than /proc and could even achieve better speed and reliability.

My friend and I had an ongoing competition / psychological experiment to psh into each other's NeWS servers and see how long it was before we would notice a some semi-subliminal or mildly psychedelic window system hack.

I was guessing you might come through and give us an awesome and thorough exposition on the parallel universe that might have been. Thanks!

I still wish anything had the features of NeWS. I wish people could currently be able to feel freedom, power, expressiveness of such environments, where you could change the look and behavior of anything on your screen with a couple of lines typed in a REPL.

Even though the browser has been creeping every day towards it, it seems impossible to escape the constriction of it's haphazard evolution. Browsers have all the hard parts of a NeWS server already worked out inside them (but in C/C++ code), but even if you could magically transform it, it seems it would still be horribly constrained by many other layers of cruft.

Writing bigger programs I struggled to understand what I wrote without comments on every line describing the stack. One could use more variables to make it easier to understand, but in the old days that would also make it less efficient. I would frequently have to reverse engineer my code.

Interestingly, object oriented PostScript would tend to help make your code seem more like prefix code, because it would be like more like "object method argument ... send" rather than "... arg arg function".

Although I admire and frequently agree with this blog, I think this article exhibits some common misconceptions about NeWS. NeWS had what amounted to uploadable toolkits, and therefore could and did have multiple toolkits. A client could decide how it wanted to separate processing between the client and server, which seems truly more flexible and allows for much more efficient communication. Also NeWS had threads which if done today would certainly use multiple processors. Clients could, but didn't have to, use a separate address space and language even. But the graphics API was so much better, it's ridiculous, and is basically the same as now in SVG, html canvas, and most other decent things.

The big drawbacks of NeWS in my opinion are not having an MIT license, and being quite difficult to implement well. Also PostScript isn't the nicest language to program in, which I say from years of programming in it. But it's far from the worst, and if one changed the to postfix syntax to prefix, it would be mostly a Lisp.

Like a literal tar fire? Or a tar format archive fire? Or is that a California expression I'm not familiar with?

Also this makes me have a sick curiosity if one could have transpiled a whole Genera world to C with cfront or something then loaded it back in with Symbolics C and have it work?

Now 30 some years later I finally see what all that weird and broken stuff in in SunView and XView was trying to do, and what a blatant but poorly executed copy it was. But now seeing how much better than Cedar/Mesa was than C, it's a wonder they even pulled that off. Sun's textedit seems a very far cry from Tioga, but they were so into it that the Sun keyboards had all the necessary keys for many years later. We could have had "buttonls" for all these years??

If you think you are having no default mode activity, you are likely fooling yourself. It is externally observable when humans have a quieter default mode, through subtleties of behavior, one can notice a calming presence, like that of non-linguistic animals. Even without language, default processing loops can be quite complex, not even taking into account multiple diverse parallel processes. Inner dialog can be very useful. Not having inner dialog is not stupid. I agree though, that in many situations, or for some people, default mode inner dialog can have a debilitating effect. But in an evolutionary way, thinking "I can survive" in a perilous situation, likely outweighs thinking "wtf I am I doing w/ my life?" when sitting on the couch. But consider the evolutionary effects of the modern externalization of inner dialog through devices.

It is the observation of linguists that some language processing is hardware accelerated. But hardware acceleration comes in a great many varieties, anywhere from having a slightly smaller partially specialized neuron group in the frontal lobe, to having genetically preconfigured sections in lower brain, to not needing the signals to travel to the brain at all, as demonstrated by headless chickens, and government officials.

It is not only healthy, but a great ability to be respected and cultivated. It is also good to learn to not do this. Saying it's unhealthy is like saying /dev/random is unhealty, but /dev/null is, or stars are bad but empty space is good. Both are quite useful. (let's please not have that talk about cryptographic qualities of /dev/random). My experience is that if you can easily tap into endless creativity and also experience the calmness of no-thought at will, you will have greater abilities than average in most situations. Meditation, among other things, can help you be more adept at either.

I'm already living in that universe, but with even more composability.

It's sad, but worse is better is so pervasive, that even many of you very smart people have difficulty conceiving of what the problem is, much less what would be a better way, not because it's particularly hard, but because of technology culture. It seems trivial. Just return an error, right?

I've had to deal with the problems of EINTR for so long. SA_RESTART seems nice, but you can't rely on it, and it only begins to scratch the surface of what would actually be "better".

How about you can call anything in a signal handler?

How about any code, user or kernel, be safely re-entered?

Of course you can't magically solve every concurrency and resource contention problem, but having functional style, and things like unwind-protect, language support for safety, etc. goes a surprisingly long way.

How about you can have arbitrarily many signal handlers for any condition and have arbitrarily many places to continue on the stack, which can receive arbitrary data?

How about I can call a system call from inside a signal handler, from inside the debugger, from inside a signal handler, inside a system call, and pop up a UI to ask the user what they want?

How about every piece of code can be moved around and called from anywhere?

How about you can pass around an objects that can resume a function or a system call in the middle?

How about the thing reading trashy network packets doesn't have absolute power, while my user process doesn't have permission to close the lid or play audio?

Not just Lisp code, but a large fraction of modern languages that have things like GC and bignums, have to make sure it's safe to do anything, even in the middle of adding a number. So why can't we have these things that have been well known for over 40 years? But I'm sure you're familiar with the relatively small set of crews that designed most the stuff we use. vmlinux, kernel32.dll, and even shabby xnu, might be cute, like the jerq is a cute joke on the perq, if we didn't have to actually rely on them for real stuff.

Unfortunately, it's not hard to see that the worse-is-better culture is a result of larger human culture, which is pushed around by the same typical things. But the good thing is that culture being intangible, it only takes the mostly mental acts of skepticism, education, and personal communication, to change it.

"Strong" AI is a person, whom you also shouldn't mistreat. Let's hope they think the same about us.