@psf@oldbytes.space

psf @psf@oldbytes.space · Jul 12, 2026

Replying to @psf@oldbytes.space

2fa doesn't help if the service you're using gets its password database leaked Disk encryption doesn't help if your OS rats you out The problem is less whether individuals follow "security best practices" and more whether corpos can be trusted one iota (spoiler warning they cannot) https://www.windowslatest.com/2026/07/10/you-cant-fully-disable-microsofts-gdid-windows-11-tracker-but-these-settings-limit-what-it-captures/

9

0

9

0

psf @psf@oldbytes.space · Jul 02, 2026

Replying to @Kazinator@mstdn.ca

@Kazinator@mstdn.ca muLISP has dynamic scope and provides no mechanism to close a function over a particular environment. So strictly speaking it has only open lambdas, not closed lambdas. It certainly doesn't have lexical closures. In certain dynamically scoped Lisps, there is a special form that solves the FUNARG problem by associating a function with a given environment so it can be called in the same environment later. Sometimes the primitive for this is called FUNCTION. muLISP doesn't have that, and looking through manuals for Maclisp and Interlisp, it is not necessarily a reliable solution for the FUNARG problem in those dialects either. I welcome corrections from anyone who has used closures in these old dialects! What is more common, is to find a hacky system for simulating closures by packaging a lambda together with a specified alist of values (not an environment). muLISP provides one: this is what "CLOSURE" is. Lisp Machine Lisp works the same way. In these dialects, the closest you get to a "closure" is something like, (LAMBDA CLOSURE-ARGLIST (CLOSURE-APPLY (QUOTE (LAMBDA (X) (* X A))) (QUOTE ((A . 5))) CLOSURE-ARGLIST)) where a lambda (LAMBDA (X) (* X A)) and an alist ((A . 5)) holding the values "closed over" are stored as arguments of CLOSURE-APPLY. The alist is mutable and used to retain the closure's state between calls. What I've done with my rplaca nonsense is manipulate several of these simulated "closures" to share the same alist, which yields the behavior I wanted, similar to writing (let ... (lambda ...) (lambda ...)) in a lexically scoped Lisp. In any modern system you would have lexical scope directly available, so you would get working closures without the need to perform such unnatural acts.

0

psf @psf@oldbytes.space · Jul 02, 2026

Replying to @psf@oldbytes.space

Aha! If you can arrange for the "closures" to share structure, then you'll have the equivalent of "multiple functions closed over the same environment". Again in muLISP: (let ((alist '(quote ((x . 1))))) (setq do+1 (closure nil '(lambda () (setq x (+ x 1))))) (setq do-1 (closure nil '(lambda () (setq x (- x 1))))) ; Now arrange for both "closures" alists to be shared list structure (rplaca (cddr (caddr do+1)) alist) (rplaca (cddr (caddr do-1)) alist)) (funcall do+1) ; 2 (funcall do+1) ; 3 (funcall do-1) ; 2 (funcall do-1) ; 1 Does any brave soul want to try the equivalent code in Lisp Machine #lisp? ;) If one was gonna do this sorta thing frequently, one could extend the closures package with a macro automating these steps.

1

0

psf @psf@oldbytes.space · Jul 01, 2026

Replying to @psf@oldbytes.space

I found a weird thing about "Lisp machine closures", at least as implemented in muLISP. In ordinary lexically-scoped #Lisp, multiple functions can close over the same variables. (let ((x 1)) (defun do+1 () (setq x (+ x 1))) (defun do-1 () (setq x (- x 1)))) (do+1) ; 2 (do+1) ; 3 (do-1) ; 2 (do-1) ; 1 In muLISP it's considerably harder to do this because the closure function creates a new alist of "closed-over values" per closure, so they are all independent. Judging by the Lisp Machine Manual, things appear to work the same way over there too. (let ((x 1)) (setq do+1 (closure '(x) '(lambda () (setq x (+ x 1))))) (setq do-1 (closure '(x) '(lambda () (setq x (- x 1)))))) (funcall do+1) ; 2 (funcall do+1) ; 3 (funcall do-1) ; 0 (do-1 is a logically separate closure) (funcall do-1) ; -1 But what you can do is close over a list and do destructive list operations. Then everyone's alist has a reference to the same list, so the closures communicate by destructively modifying the list. I have no idea if this is just a dirty hack or if people used this in practice. (let ((x (list 1))) (setq do+1 (closure '(x) '(lambda () (incf (car x))))) (setq do-1 (closure '(x) '(lambda () (decf (car x)))))) (funcall do+1) ; 2 (funcall do+1) ; 3 (funcall do-1) ; 2 (funcall do-1) ; 1

1

0

psf @psf@oldbytes.space · Jun 30, 2026

"I always worked with programming languages because it seemed me that until you could understand those, you really couldn't understand computers. Understanding them doesn't really mean only being able to use them. A lot of people can use them without understanding them." -- Christopher Strachey, quoted in Anatomy of #Lisp Of course, now we also have machines that use them without understanding them.

0

psf @psf@oldbytes.space · Jun 19, 2026

muLISP has an interesting way of implementing lexical-style closures in a dynamically scoped #Lisp, a method it claims to be "patterned after the Lisp Machine LISP dynamic closure package". $ (setq quintupler (let-closed ((a 5)) '(lambda (x) (* x a)))) (LAMBDA CLOSURE-ARGLIST (CLOSURE-APPLY (QUOTE (LAMBDA (X) (* X A))) (QUOTE ((A . 5))) CLOSURE-ARGLIST)) $ (setq b 6) 6 $ (setq sextupler (closure '(b) '(lambda (x) (* x b)))) (LAMBDA CLOSURE-ARGLIST (CLOSURE-APPLY (QUOTE (LAMBDA (X) (* X B))) (QUOTE ((B . 6))) CLOSURE-ARGLIST)) (btw lambda being followed by an atom like CLOSURE-ARGLIST rather than a list is how muLISP does varargs, so don't be confused by that part like I was) You can see that it packages up the values of captured variables in an alist. CLOSURE-APPLY puts those variables into scope, calls the function, then when it's done, packages those variables back into the alist for later.

5

0

1

0

psf @psf@oldbytes.space · May 08, 2026

Replying to @gloriouscow@oldbytes.space

@gloriouscow@oldbytes.space @netkitty@meow.social wow how'd you get in there?

2

0

psf @psf@oldbytes.space · May 05, 2026

Replying to @arclight@oldbytes.space

@arclight@oldbytes.space The speed difference is less from LLMs than from dependency philosophy. In LLM land I was in "slam dependencies together until they kinda work" mode. LLMs are great at turning boilerplate generation/glue code/dependency wrangling into "type a few words then grab a sandwich". As a result of this crutch, large modern frameworks and languages become a lot more usable, almost fun? But this is enabling complexity, not removing it; there's still no hope of fitting the system in your head. Sometimes it seems that LLM use is like an outgrowth of library culture. If you are using libraries, you already don't understand those parts of your program that are handled by the libraries. LLMs extend that by allowing you to also not understand the part that you "wrote". This is the opposite of how I use Forth: in my current project I have no libraries and only a subset of ANS Forth. It's slower to build ground-up from a tiny set of primitives, than to use premade libraries, but it's also one of my art forms. When I don't do it for a while, I miss it.

3

0

psf @psf@oldbytes.space · May 05, 2026

I fell into a LLM rabbit hole for a few months. I am now out of that hole and hacking on #forth code again. My brain is shocked by how slowly I am moving. And yet, I feel whole again.

19

6

3

0

psf @psf@oldbytes.space · Apr 30, 2026

Replying to @gloriouscow@oldbytes.space

@gloriouscow From what I've been able to piece together, the Bulova watch available was (at least at one point) one of the tuning fork Accutrons - way cool!

0

psf @psf@oldbytes.space · Mar 20, 2026

Replying to @jack@status.sexyferret.science

@jack@status.sexyferret.science thanks for giving me the opportunity to clarify my take, because the "past good, future bad" framing was probably the weakest part of it. my actual point is that software is the product of its environment. software created in a repressive environment reflects the greed and paranoia of its creators. there are plenty of examples of this in the past; Microsoft were greedy and paranoid, David Ahl and the Creative Computing crew weren't, and when you use their software, the difference is stark. today there is still plenty of software (usually FOSS) that hasn't been dragged down by extractive greed. however, pretty much all of the dominant players have succumbed to the perverse calling of adtech and data brokerage. there are people entering the field today who have never seen a website without targeted ads, an operating system without always-on telemetry, or a video game without microtransactions, and it's mainly #retrocomputing heads who are in the position to point out these thing are a product of the fucked up environment we live in, not an inherent trait of software, and that we can do better when creating new software. put another way, retrocomputing is the most interesting to me when it isn't just based on blind nostalgia for the past, but instead focuses on understanding what past systems Got Right and what use we can still make of them today.

41

1

14

0

psf @psf@oldbytes.space · Mar 19, 2026

Replying to @profbib@layer8.space

@profbib@layer8.space To give credit where credit's due, I got "bicycles for the mind" from Steve Jobs, who, knowing him, probably got it from someone else.

4

0

psf @psf@oldbytes.space · Mar 18, 2026

software is a mirror that reflects the times and the environment it was created in.

this is why much software created in the 1970s counterculture was joyful and humanistic, and why much software created in the 2020s capitalistic hellscape is soul-crushing malware (adware, spyware).

#retrocomputing can mean celebrating hardware limitations and creative coding, but it can also mean celebrating personal computing - computers that are tools for liberation - bicycles for the mind, not cattle trains to the slop farm.

382

19

271

3

psf @psf@oldbytes.space · Jan 09, 2026

Replying to @PurpleJillybeans@kind.social

@PurpleJillybeans Upgrade to MS-DOS and you'll be good until 2099.

3

2

0

psf @psf@oldbytes.space · Jan 07, 2026

Replying to @akkartik@merveilles.town

@akkartik@merveilles.town @kirtai@tech.lgbt @millihertz@oldbytes.space Yeah I'll step back from litigating the definition, that's no fun for anyone. Growing slowly and thoughtfully can involve a lot of distillation, too.

4

0

psf @psf@oldbytes.space · Jan 07, 2026

Replying to @kirtai@tech.lgbt

@kirtai@tech.lgbt @millihertz@oldbytes.space If it grows over time, that runs counter to the distillation idea. Shrinking over time is so rare....

0

5

0

psf @psf@oldbytes.space · Jan 06, 2026

Replying to @psf@oldbytes.space

The best example of distilled software that comes to mind is Project #Oberon, which was distilled by Niklaus Wirth (and others) for most of Wirth's lifetime (if you count his earlier time working on Pascal and Modula as earlier steps of the distillation). https://projectoberon.net/ There are also #Forth and #Lisp, of course, but they've been distilled in many different directions by many people so there isn't a clear unifying idea. You have to get more specific. Now, Chuck Moore's evolution of Forth -> MachineForth -> ColorForth certainly counts as distillation. #LuaLang also comes to mind. Porting the most modern Lua to the 188K TI-92+ calculator (last year) is what sold me on the idea that widely used modern software can remain useful on the oldest computers. That said, Lua is not entirely immune to bloat: I had to roll back from v5.4 to v5.2 to cut my memory usage from ~170K to ~128K 😉

14

1

6

0

psf @psf@oldbytes.space · Jan 06, 2026

principles of software distillation:

Old software is usually small and new software is usually large. A distilled program can be old or new, but is always small, and is powerful by its choice of ideas, not its implementation size.

A distilled program has the conciseness of an initial version and the refinement of a final version.

A distilled program is a finished work, but remains hackable due to its small size, allowing it to serve as the starting point for new works.

Many people write programs, but few stick with a program long enough to distill it.

117

17

61

0

psf @psf@oldbytes.space · Oct 09, 2025

Replying to @psf@oldbytes.space

I will never stop beating the "2fa is security theater" drum. Nowadays companies just get their Juicy User Info database directly stolen, and password security / 2fa is relatively unimportant for the end user. The push to get end users onto 2fa (let alone shit like PassKeys) without also levying criminal penalties on corporations that leak their database, is akin to putting water restrictions on households while not regulating big industrial water users. A complete fucking disgrace. https://www.theverge.com/news/797051/discord-government-ids-leaked-data-breach

18

1

9

0

psf @psf@oldbytes.space · Mar 21, 2024

The war on password login is tiresome. "Security best practices" often do not take into account the security/convenience trade, especially when the account in question is low value or already protected by a strong security boundary.

4

1

0

psf

Posts

Remote instance