rahen

> Basically what he said was that lisp ended up not working well for larger software projects with 5 or more people on them

I don’t think "doesn’t work for teams of 5+" is a fair generalization. There are production Clojure and Emacs (Lisp) codebases with far more contributors than that.

Language adoption is driven less by inherent team-size limits and more by social and practical factors. Some students probably don't like Lisp because most people naturally think in imperative/procedural terms. SCIP was doing a great job teaching functional and symbolic approaches, I wish they hadn't shifted their courses to Python, since that increases the gravitational pull toward cognitive standardization.

Lisp didn’t really disappear, symbolic AI did.

Lisp was ideal for reasoning systems, its homoiconic and meta-programmable nature is perfect for manipulating symbolic structures and logic. But when AI shifted toward numerical learning with neural networks, tensors, and GPU computation, Lisp’s strengths mattered less, and Python became the new glue for C/CUDA libraries like NumPy, PyTorch and TensorFlow.

Still, nothing prevents Lisp from coming back. It would actually fit modern deep learning well if a "LispTorch" with a CUDA FFI existed. We would have macros for dynamic graph generation, functional composition of layers, symbolic inspection, interactive REPL exploration, automatic model rewriting etc.

We almost had it once: Yann LeCun’s SN (the first CNN) was built on a C core with a Lisp interpreter on top to define, develop and inspect the network. It eventually evolved into Lush, essentially "Lisp for neural networks", which in turn inspired Torch and later PyTorch.

https://x.com/ylecun/status/1944504502260003296?lang=en

So Lisp didn't die in AI, it's just waiting for the right people to realize its potential for modern neural networks and bring it back. Jank in particular will probably be a good contender for a LispTorch.

https://github.com/jank-lang/jank

Did you really use vi on DOS in 1991? I don’t remember Elvis being easy to find back then, and I don’t think it was a TSR either, so the compiler couldn’t be spawned in the background like it was with the Borland IDEs.

Almost every C bedroom programmer I knew had a cracked copy of Turbo C / Turbo C++ because they were so modern and convenient. DJGPP was a nightmare in comparison, it filled up the small HDDs of the time, created large executables, and the process of opening edit.com, leaving the editor, running gcc, and then going back to edit.com was tedious.

The few brave souls using DJGPP would usually end up running Slackware from around 1993. This was a step up from bolting an awkward POSIX runtime onto a monotasking system, as DJGPP did on DOS.

DJGPP was a stellar idea, basically the WSL / MinGW of the days, but the limitations of DOS prevented it to shine compared to the Borland IDEs.

Isn't it the same for all mining activities, including gold? You typically spend a massive amount of energy digging and processing earth to recover a few grams of gold, and that energy isn't recoverable.

Indeed, it must have legal value. Even so, some stores accept Bitcoin and Monero (thus making them money) but won’t accept USD in Europe or Euros in the US, so you can't use them despite those currencies having legal tender status.

So yes, whether Bitcoin is money or a security remains an open question.

Isn't money just bits too nowadays?

As far as I understand, Bitcoin is backed by energy and scarcity, much like gold: it requires significant energy to "mine" a Bitcoin, and it can't be easily duplicated, if at all. That's its intrinsic value, unlike fiat currencies that can be printed easily (correct me if I'm wrong).

I also believe that even gold has little intrinsic value, perhaps even less than steel. Ultimately, it's really a question of how valuable something is as a medium of exchange. Bitcoin is durable, portable, divisible, scarce, verifiable, and decentralized, which makes it a valuable form of currency. I suppose that's its exchange value.

I highly doubt that, considering Stallman's stance on freedom and personal sovereignty. Free software often operates like market anarchy (pure meritocracy), similar to the Internet. Coercive structures of centralized power that dictate what the 'common good' is do not align with the principles of the GPL. Also the GPL is focused on enforcing property rights ("this is yours unconditionally"), while communism emphasizes transferring property to the government ("this is ours but you might have some if you behave").

Can you be more specific about why you are not upgrading to Tahoe concerning software freedom?

For some, it’s the sheer grandeur and architectural splendor. Strasbourg, Chartres, Cologne or Rouen Cathedrals, with their scale and delicate designs, often stand out.

For others, it’s the spiritual resonance of a place. The Cathedral of Santiago de Compostela has stirred something deeper within, but maybe that was just me. I experienced the same with Lourdes and Le Puy-en-Velay in France because they carried something that felt "sacred" and transformative, not only from the buildings but the actual place.

Then there are those who value historical or religious authority. Cathedrals like St. Peter’s in Rome or the Papal Palace in Avignon have that kind of symbolic weight, and I assume some would favor them over the more "profane" work of Gaudi.

I use Emacs (org-mode with TeX and Beamer exports) for almost everything, it's my office suite among other things. The only time I still need LibreOffice is for diagrams and charts, and even that is slowly being replaced by Mermaid.

https://ridaayed.com/posts/create-diagrams-in-emacs-org-mode...

This is the first thing that came to my mind. Why pick an OCI container instead of an LXC container since it's a stateful workload?

Going OCI here only makes sense for temporary, disposable sessions.

This is odd. The current hash rate is around its nominal 5 GH/s, and neither any pool nor individual seems to be above 50%:

https://miningpoolstats.stream/monero

This Qubic group claims to concentrate 3 GH/s of hashing power, yet there has been no increase in the global hash rate either:

https://www.coinwarz.com/mining/monero/hashrate-chart

Could this be just a bait?

LXD was forked as Incus, and it’s an absolute delight.

Seamless LXC and virtual machine management with clustering, a clean API, YAML templates and a built-in load balancer, it's like Kubernetes for stateful workloads.

This is worth undertaking. macOS's stricter approach to handling some questionable hacks in Emacs could improve the codebase across all platforms. The PGTK frontend for Emacs (the Wayland-native frontend) was derived from the macOS version for instance. It replaced much of the messy X11 code with a cleaner, more modular Cairo-based frontend, which could be further enhanced by adopting a cross-platform, more future-proof SDL toolkit.

https://appetrosyan.github.io/posts/emacs-widget

Hopefully, similar improvements can address the issues with large locks and the lack of proper threading.

You shouldn't root Graphene, it breaks its security model and is certainly the reason why Revolut doesn't work on your phone. It works like a charm on mine.

Just build it yourself. Or you can install glibc on both Void and Alpine, if you want the pre-built binary.

This sounds plausible and fascinating. Let’s see what it would have taken to train a model as well.

Given an estimate of 6 FLOPs per token per parameter, training a 7B parameter model would require about 1.26×10^22 FLOPs. That translates to roughly 500 000 years on an 800 MFLOPS X-MP, far too long to be feasible. Training a 100M parameter model would still take nearly 70 years.

However, a 7M-parameter model would only have required about six months of training, and a 14M one about a year, so let’s settle on 10 million. That’s already far more reasonable than the 300K model I mentioned earlier.

Moreover, a 10M parameter model would have been far from useless. It could have performed decent summarization, categorization, basic code autocompletion, and even powered a simple chatbot with a short context, all that in 1984, which would have been pure sci-fi back in those days. And pretty snappy too, maybe around 10 tokens per second if not a little more.

Too bad we lacked the datasets and the concepts...

Reductio ad absurdum. A 300K-param model was small enough to be trained offline, on curated datasets, with CPUs and RAM capacities that absolutely existed at the time, especially in research centers.

Backprop was known. Data was available. Narrow tasks (completion, summarization, categorization) were relevant. The model that runs on a Pentium II could have been trained on a Cray, or across time on any reasonably powerful 90s workstation. That’s not fantasy, LeNet 5 with its 65K weight was trained on a mere Sun station in the early 90s.

The limiting factor wasn’t compute, it was the conceptual framing as well as the datasets. No one seriously tried, because the field was dominated by symbolic logic and rule-based AI. That’s the core of the argument.

You’re basically arguing that because A380s need millions of liters of fuel and a 4km runway, the Wright Flyer was impossible in 1903. That logic just doesn’t hold. Different goals, different scales, different assumptions. The 300K model shows that even in the 80s, it was both possible and sufficient for narrow but genuinely useful tasks.

We simply weren’t looking, blinded by symbolic programming and expert systems. This could have been a wake-up call, steering AI research in a completely different direction and accelerating progress by decades. That’s the whole point.

You're missing the point. No one is claiming that a 300K-param model on a Pentium II matches GPT-4. The point is that it works: it parses input, generates plausible syntax, and does so using algorithms and compute budgets that were entirely feasible decades ago. The claim is that we could have explored and deployed narrow AI use cases decades earlier, had the conceptual focus been there.

Even at that small scale, you can already do useful things like basic code or text autocompletion, and with a few million parameters on a machine like a Cray Y-MP, you could reasonably attempt tasks like summarizing structured or technical documentation. It's constrained in scope, granted, but it's a solid proof of concept.

The fact that a functioning language model runs at all on a Pentium II, with resources not far off from a 1982 Cray X-MP, is the whole point: we weren’t held back by hardware, we were held back by ideas.

I would have thought the same, but EXO Labs showed otherwise by getting a 300K-parameter LLM to run on a Pentium II with only 128 MB of RAM at about 50 tokens per second. The X-MP was in the same ballpark, with the added benefit of native vector processing (not just some extension bolted onto a scalar CPU) which performs very well on matmul.

https://www.tomshardware.com/tech-industry/artificial-intell...

John Carmack was also hinting at this: we might have had AI decades earlier, obviously not large GPT-4 models but useful language reasoning at a small scale was possible. The hardware wasn't that far off. The software and incentives were.

https://x.com/ID_AA_Carmack/status/1911872001507016826

I know most people couldn’t care less about this, but those gimmicky animations probably consume more computing power than the entire Apollo project, which strikes me as unnecessary and wasteful. Given the choice, I’d much rather have a clean, efficient interface.

I tend to like Material Design in comparison. It’s clean, efficient, and usable. I just hope Google won’t try to "improve" it with annoying gimmicks and end up making things worse, like Apple did here.

No need for an RPi 5. Back in 1982, a dual or quad-CPU X-MP could have run a small LLM, say, with 200–300K weights, without trouble. The Crays were, ironically, very well suited for neural networks, we just didn’t know it yet. Such an LLM could have handled grammar and code autocompletion, basic linting, or documentation queries and summarization. By the late 80s, a Y-MP might even have been enough to support a small conversational agent.

A modest PDP-11/34 cluster with AP-120 vector coprocessors might even have served as a cheaper pathfinder in the late 70s for labs and companies who couldn't afford a Cray 1 and its infrastructure.

But we lacked both the data and the concepts. Massive, curated datasets (and backpropagation!) weren’t even a thing until the late 80s or 90s. And even then, they ran on far less powerful hardware than the Crays. Ideas and concepts were the limiting factor, not the hardware.

So if I understand correctly, the hardware paradigm is shifting to align with the now-dominant neural-based software model. This marks a major shift, from the traditional CPU + OS + UI stack to a fully neural-based architecture. Am I getting this right?

I'm not sure anyone invoking "classic Unix" is pining for modem noise or line printers, though that seems to be how you're interpreting it. That’s more a caricature of early computing than what defines the Unix philosophy or what NetBSD preserves.

When I say classic Unix, I really mean "simple software":

- Text-first, scriptable interfaces where tools do one thing well and can be composed

- Human-readable configuration in plain files, no XML or opaque binary blobs

- Predictable, minimal system design where you can understand what’s happening under the hood without chasing abstraction layers

- Manual pages that matter, and a userspace that favors understanding over wizard-driven opacity

- A system that’s BSD-like in spirit: clean, coherent, documented, and built by people who care more about correctness and clarity than flash or trends

This is in contrast to modern Linux distributions where systems are often a tangled mess of systemd units, layers of more or less obscure daemons and processes, unpredictable behaviors, and YAML/JSON/XML-based abstractions that sit between you and the actual system.

So no, I'm not glorifying the past or pretending users in 2025 would enjoy a serial terminal setup from 1984. I’m saying that a clean, simple, consistent, modular Unix, in the traditional sense, is still valuable and NetBSD is one of the few OSes that still embodies that ethos.

Interesting perspective. sysinst could certainly use better ergonomics, but I wonder whether he’s really approaching NetBSD like a typical user would - someone after a classic Unix experience on modern hardware.

With an old-school Unix mindset myself, I’ve always found the CLI installers of OpenBSD and Alpine Linux cleaner, more straightforward and in line with that philosophy. Honestly, I’d rather see sysinst replaced by something along those lines.

It still looks a lot more legible than a TECO script. ed was a big improvement in ergonomics.

Isn't this violating the first rule of AI safety: do not let an AI change its code?

You can mount a data partition inside, so the 16GB limit is really just for the system.

If by any chance you're an Emacs user, check out Eshell. It blends Elisp macros with shell commands, and since it keeps the buffer model, you can use all the usual Emacs tools for searching, sorting, and more. It's a unique shell with some learning curve, but it's mature and powerful.

https://www.youtube.com/watch?v=9xLeqwl_7n0