Floppy PNG

When you build Rust, at least the way I'm compiling it, it requires internet access. Further, it uses a Python script to pull source packages via curl. This also means that you need an updated set of certificates. My build for everything else is 2022. Everything else I compile can just be a simple compile from a tarball. But no, Rust is the always-in-motion, always-need-cloud, always-need-updated-certs, gigs-of-framework-snapshots kind of thing with crates, etc. And nobody using Rust even understands why this is a problem. I'm kind of surprised that so far Rust is supplying the legacy packages it is downloading. The *entire reason* for N🚫NIC is for this very reason. Why do we need a NIC? There is so much we can do with a computer without a NIC. True, I do mostly web dev stuff now. Even my scripting engine of choice is Deno/Javascript (was Perl for 30 years... I drank a beer with Larry Wall in a tent in 1999 in Monterey, 15 feet away, and he didn't know I was there, but still... *that close* to Larry Wall. Miguel de Icaza was also at that same conference and when demonstrating Bonobo on Gnumeric related how he thought "Crazy Grandmother in the Attic" was a great name, but settled on Bonobo). Whew. I really do like **computers*. And, no, the network is *not* the computer. What did all that networked collaborative knowledge get us in the end? Subscriptions to LLMs? Constant gigs of data downloads patching our phones and computers? (And!! the main audience for this post is mostly Nostr/Bitcoin folks who think a distributed set of nodes needed to buy a pizza with your phone is a good thing. Here's 20 bucks! It's paper. I don't have to update one single thing to spend it. Like Steve Martin, I can keep the bills from sticking together by making the bills into little balls if I desire. Freedom!!??? My-o-my, that is relative.)

Compiling LLVM is a beast. Great test for my dead simple web app w/ local compile. Nothing has timed out on the response object so far... this one probably will, but notice that Deno is handling the task locally, not my web client tunneling to the VM.

I'm working on my build system this morning making minor tweaks to simplify it and building the system up through LaTeX. Perhaps I'll even get to #e16. It reminded me that there is never a truly predictable complicated system IRL. This reminds me of when I was monitoring thousands of servers. Even if the same exact model was purchased, the data coming back was always slightly different. The NIC or SPU or MB had different characteristics that made automating the deployment tricky at a certain level of detail. I know we put layers upon layers of things to try and make this not so with containers and declarative OSs like NixOS. *Perhaps*, if you have control of the full supply chain, some things are controllable if it is a priority, but that isn't practical with any system I've worked with. True, I used to drive my vendors crazy by asking for exact models of SCSI drives and controllers. (I ran SCSI in the 90s vs. IDE as a general rule). Anyhoo... I could make the build system more automated, run through all of the steps in sequence, or look at dependency graphs to determine the next compile, but the most useful form my stuff is likely just the shell script and the LFS/BLFS entry. This is a similar issue as "resilience". Resilience happens at time of crisis. An abstract of one of my favorite articles: "In domains concerned with global change, achieving resilience in socio-ecological systems is highly desired; however making this concept operational in reality has been a struggle partly due to the conflation of the term by these domains. Although resilience is vastly researched in sustainability science, climate change and disaster management for some reason this concept is not dealt with from an ontological perspective. In this paper, the foundation for a formal theory of resilience is laid out. I propose that the common view of resilience as ‘the ability of a system to cope with a disturbance’ is a disposition that is realized through processes since resilience cannot exist without its bearer i.e. a system and can only be discerned over a period of time when a potential disturbance is identified. To this end, the constructs of the Basic Formal Ontology are applied to ground the proposed categorization of resilience. In so doing, I adhere to the notion of semantic reference frames by employing a top-level ontology to anchor the notion of resilience." Daniel Desiree. 2014. “Resilience as a Disposition.” in Frontiers in Artificial Intelligence and Applications. IOS Press. We like to have control. We want to see a map from the present to a future state, despite disruption events. We also want frictionless wins, a custom built OS. But, there is always some form of trade-off. Back to the topic: If I run top in a window to watch the build go, display the script I'm running, kick it off in the background, and refer the reader to the LFS/BLFS documentation if it exists for the build step, running one step at a time, overall that system will prove to be more resilient to the reader than a tested and refined sequence. This is *particularly* true for LFS builds, as upgrading the CPU might break the whole system. Put another way, for anybody that has attempted an LFS build, my guess is something *always* goes wrong at some point. In the end? Remember that every framework or abstraction exposes you to risk as far as resiliency. Do I need to fully understand Glibc? No. But having a slightly different version of basic OS libraries in every container and expecting to maintain code that is increasingly created by scraping/matching, no matter how excellent that match is, is not particularly resilient. Now, here is the vector we are on, and the exception. If we are fed as consumers constantly and just toss out whatever we don't like, and accept the new food/gruel of the day as part of our subscription, with massive engines grinding out supposedly better and better gruel, then we don't have to analyze. We don't need to be resilient. We depend on corporations (or crowdsourcing/hive mind) to always appear like we are moving forward. Perhaps we are. Finally... it is never all or nothing. There is always some kind of middle ground. This is particularly true in the open source world. Every one of these packages represents a huge effort by many people with skill high above my own. LFS/BLFS books are created by people who truly understand what is going on underneath. For that matter, Debian, which is package based, not source based (from the user perspective) is often a much more sane alternative. The main reason why I'm going back to NoNIC for #e16 is because I realized how complicated the window manager/display manager/systemd had become. And, like the above thread, that complication threatens resilience depending on the system.

I'm using a removable ~100GB SSD drive with 30G root, 10G swap and the rest for source/build files. This means I can back up the whole thing, partitions and all, with a single command: ``` dd if=/dev/sdb of=/dev/sdc ``` Just make doubly sure that you get the device right. I'll figure out a better sync later for changes, but as of now I have only changed one build step from my 2023 work. Back when I was rolling out thousands of Windows95 workstations, I had large tower boxes running Slackware. I had my crew run dd commands to mirror the systems. It was free. This was before more fancy mirroring software came out, and before MS started insisting on a unique machine identity. You'd go in the back room before a large deployment and there were cables dangling everywhere with drives hanging on the end and GNU/Linux sessions on the screen.

The last PiLFS images are also around LFS 11.2. I'm going to focus on x86_64, as there are loads of old Windows boxes out there that are increasingly useless (and I have quite a few as well). But, it doesn't take much to get QEMU running on an M1+ macOS system using these images. https://intestinate.com/pilfs/

I did get the 5.15 kernel recompiled after recompiling GCC with new headers and other related stuff, including Glibc. The system should be pretty solid on 5.15 now. I'll eventually do another full pass. Sometimes you have to go back and forth with the toolchain. I messed up a wee bit on grub, but no sweat, SystemRescueCD to the rescue: ``` qemu-system-x86_64 -cpu qemu64 -enable-kvm -smp 6 -m 12G -boot d -cdrom systemrescue-12.02-amd64.iso -drive file=/dev/sdb,format=raw ```

Downgrading the kernel to 5.15 from 5.19 was uneventful. make oldconfig worked fine without warnings, just a bunch of added drivers/features. Here the build system is building Glibc against the new Linux headers. The compile finished fine. You can see the chain of commands running locally on NoNIC within the QEMU VM (ssh into VM, bash, Deno run of build.js script that serves the web page on the left, runs the current shell command curr.sh, and finally make within glibc)

I got a build tool running today. I pass parameters on the URL for the step and if run is desired. I track whether Deno has run the command in an object so it doesn't run twice. Deno kicks off the shell script and shows results if successful, and error if not. With it barely running, it is only 62 lines of JavaScript for the entire app. #e16

There was a long period of time when I lived with Punks and Hippies and other fringe subcultures where I had no access to MTV. In the punk house I lived in (one of two in the early 80s) we had a giant old tube Color TV. The back was off, so it was just a huge cathode ray tube wrapped in copper wire with the convergence knobs on the circuit board around the yoke and the single wire going to the flyback transformer that would glow slightly in Tesla-blue electric in the dark room filled with cigarette smoke as we watched The Wall, Suburbia (Spheeris) and Rise and fall of Western Civ I (also Spheeris). 20 of us drinking and smoking, packed in the living room. The tuner on the TV didn't work to receive broadcasts, but we could play tapes. We were quite a scene going down to rent a tape and a VCP (video cassete player), 10 punks and me, always the normie with the ID to actually rent stuff. When I look up a YT song from that period, it is often first time I've seen it. Here is one vid from those transient times that I was thinking of, but didn't see until today: https://youtu.be/LQiOA7euaYA I have had *way too much fucking fun*. I'll tell ya.

If you need a quick little JavaScript program to test terminal colors and your runtime, Fabrice Bellard put one up in the tests directory of his Micro JS (which does ES5 in under 10kB memory): https://github.com/bellard/mquickjs/blob/main/tests/mande…

Working on the combined CSS/HTML/JavaScript/BASH, as I come up with a minimal build system that can be hosted on a minimal GNU/Linux OS via Deno, reminds me of a story. In ’94 I was introduced to a couple that wanted to talk urgently to somebody technical. The friend that introduced me ran a local computer magazine that I had written a couple of articles for. The couple was a man and his wife (or lover), but he was much more animated. She was somewhat grim, and mostly silent during his talk with me. We met at one of the new pubs that was going up in downtown, those trendy places that would overrun many downtown cores, which I also enjoy. I don’t remember the name. He had a notebook filled with notes, different Internet addresses (it was capital I back then… I don’t want to dead case the internet). He told me that the Internet was so powerful that I needed to get connected and download software before it was made illegal. He showed me where to get Mosaic, which I used for several years afterwards. I left with some of his sense of urgency rubbed off on me, and a sheet of paper with notes and links. I remember using Mosaic to find Netscape for awhile. I’m not sure why I needed the two-step. Perhaps there was no FTP site for Netscape? Maybe I only had my note he gave me on a piece of paper? I have to say, looking back, that the power of the internet was hijacked, taken away from most people. Most don’t use it in the powerful way it could have been used. For awhile it seemed like we would. People had websites, wrote HTML, etc. We faded, though. Our attention drifted to our feeds, both in our personal life but in our agile sprints. Hmmmm… hijacked implies some dark force, but, no, we fell under the crush of attention and complication as we built our way to collapse. But all of that is one possible universe. It isn’t over yet. The thing I am most fascinated about is the persistence of ideas, persistence beyond any individual person. True, that is culture. That is how we built civilization, right? I just think that the internet and compute and storage, the plateau we reached, has opportunity for persistence of ideas and learning that break out of the black iron prison (BIP ©️ Philip K. Dick). That is where my approximation of hope plays.

I missed the Palmer Eldrich PKD connection. I thoroughly enjoy this movie. "Jesus Shows You The Way To The Highway is a carefully blended mixture of styles and elements that seems at first to be nothing but chaos but slowly coalesces into a very strange gestalt. It feels like a Guy Madden film in its awkward artificial clunkiness, but it also contains elements of The Matrix, James Bond and Batman. It looks and smells like a comedy, but it isn’t, well it is, but it’s more a pastiche than a parody" https://filmofileshideout.com/archives/miguel-llansos-jes…

Lazy marker for me, and perhaps useful to readers. One edge I need to reach is the Node plus toolchain needed to run MDN offline using yari and content. This includes quite a bit of Deno's web API, which QuickJS doesn't include. https://github.com/mdn/yari

Regarding the design decision about graph vs sequence: A graph is great to shuffle dependencies. For instance, I might find something that is needed further down the toolchain. By using a graph of dependencies, I can fix that. However, I have never found that something breaks in a GNU/Linux system that can't be fixed with a sequence recompile. Further, even in the simplest system, I'm aware of self-referential nodes, where you have to compile A, then B, then A again before it works correctly (Freetype sticks in my head as one of those, and there are others). The major distributions have also shown the complications of graph-style dependencies. How many times have you used apt or rpm and ended up at a system state you couldn't fix? Then we have tools to fix the tools. Plus, this is for a fixed way to always be able to read/modify/use a particular application over time as well as toolkit documentation, not as a general purpose OS that would be much better served with a popular distro that fits your needs. Off hand, I'm thinking I can get to #e16 and basic server infrastructure for local knowledge management apps with less than 250 steps (source packages). Nonic itself is 77 steps: https://nonic.org/

Nostr bots are getting slightly better. At least they aren't just repeated follow... we are so fucked. Everybody's experiment with a VC north star. Barriers to entry are so *thin* on Nostr (just a private key signing an event object and open relays). Bill Joy's grey goo isn't material, it is *data*. All our interactions are feed to be disassembled with his GNR metaphor, centralized, and sold back to us.

VSCodium might end up being an excellent tool for this anyway, as it does natural sort for the build scripts. I like keeping the scripts separate, as stuff like key OS, kernel/drivers and SSH are useful without any system on their own. (Tweak the build script and just run it on its own.)

Today's coding motivation: Porcupine Tree - Stars Die: The Delerium Years compilation #CodingMusic #NowPlaying

I worked on developing the build script with vi for much of yesterday, as NoNIC has few tools OOTB. It does have SSHD running and networking through the forwarded QEMU port. I've become used to the look, feel, and features of VSCodium, though, and have been raw dogging with vi in the meantime. I have the vim keybindings and other features like / search running with VSCodium, so I can move back and forth easily to vi, using decades of muscle memory. I was sitting down to do some more coding on the build system, and remembering the motivation and build systems I've built in the past, specifically tho original NoNIC from 2006, which was motivated by maintaining a consistent OS for my journal software, Mountain Climbing Journal. That journey, like my homebrew Z-80, had periods of intense work as I had breaks in employment and/or a need to create or divert my worry/anxiety/dread into something productive. As I started work, I felt the urge to mount via sshfs so I could use VSCodium. Yes! This was the correct approach, something I used frequently in my 2010 push. #e16 #nonic #sshfs #mcj

Found this in my www surfing this morning. #technology #StrikeALight #FireDrill https://doi.org/10.1017/S0959774322000439

The full log of my #e16 journey is posted in reverse chronological sequence here: https://codeberg.org/144mb/nostr-push-log/raw/branch/main… I don't check it in as often as my Nostr posts, but it is likely an easier way to get the full log for the e16 build. Other stuff like the build system itself will be in the same repo. I have another mirror up on SourceForge here that will also have the code and log: https://sourceforge.net/p/nostr-push-log/code/ci/main/tree/