psf

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/

@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.

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.

@flyingsaceur@ioc.exchange MS-DOS 5.0 in ROM in a HP #200LX on a sunny park bench. #hp200lx

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 😉

@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.

@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.

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.

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

@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.

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

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.

@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!

"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.

@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.

My general point is that 2fa intends to help with the hop between the user and the service provider, but doesn't help with other hops, and nowadays those tend to be the weakest links. The number of times I've suffered a security incident due to a weak password or getting phished is zero. The number of times I've suffered a security incident due to my service provider getting popped is... well I've lost count. Meanwhile every service provider treats me like a stone age heathen for eschewing 2fa, and increasingly I'm not even offered the choice. That's victim blaming. @mjg59@nondeterministic.computer if by "actual cryptography" you're talking about something like homomorphic encryption that allows service providers to process my data without understanding it, that'd address my concern, but I am not sure entirely what you mean.

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