Honestly, I can’t support Y Combinator (by contributing to this site) after the CEO does something like this without repercussions—song lyrics or not.

This is schemescape signing off.

Last I checked, Lua was “bring your own debugger”. Assuming that hasn’t changed, a REPL is nice, but you can’t pause and inspect anything by default.

To be the most fair, Fennel 1.4 recently released with an `assert-repl` form that opens a repl when some assertion fails, in which you can inspect local variables, etc. That's getting closer to CL.

https://git.sr.ht/~technomancy/fennel/tree/1.4.0/item/change...

Thanks for the correction! I had only used Lua, and thought Fennel had no runtime, so I assumed this was not possible.

Fennel has a form `assert-repl` which will drop into the REPL wherever, if the condition fails. For writing games you can launch the REPL in the game loop if a keyboard button is pressed. But what you can't do, that I know of, is interrupt arbitrary execution and get a Fennel REPL. You'd probably need a lua debugger of some sort for that. I'm not that familiar with that though.

Why can't you just put the equivalent of `(repl)` wherever you want to debug and drop into your REPL?

Short answer: I don’t know. That sounds like a good idea, but how would that access local variables in the caller (to inspect state)?

I remember the Lua C API exposes a lot of information, but I didn’t think it was accessible from scripts. Of course, it was a long time ago and I could have easily missed something at the time. Happy to be corrected!

Edit: you might also run into difficulties trying to redefine non-global functions to add the call to “repl”.

Good list! I, too, have many complaints about Common Lisp.

But for a language whose standard hasn’t been updated in roughly 30 years, it holds up impressively well!

What are the quirks of static linking you need to work around (in general, not for glibc)?

You have to know the internals of your dependencies so you can link them explicitly, recursively. (admittedly, pkg-config helps a ton, but not all libraries ship (good) .pc files)

Global constructors no longer reliably fire unless you are extremely careful with your build system, nor do they run in a predictable order (e.g. you can call a library before it is actually initialized, unlike dynamic linking where only preinit - which nobody uses - is weird), nor can you defer them until dlopen time if you want (which is, admittedly, overdone).

It's possible to link to parts of multiple versions of a library (remember, you have to recurse into your dependencies), as opposed to dynamic libraries where at least you're guaranteed all-or-nothing (which is much easier to detect).

Linking is slower since it always has to be redone from scratch.

Not resilent against system changes. For example, old versions of `bash-static` (grab them from e.g. Debian snapshot and extract them manually; don't install them) are no longer runnable on modern systems since certain system files have changed formats, whereas the dynamically-linked `bash` packages still run just fine.

It also encourages bad stability habits, leading to the equivalent of NPM hell, which is far worse than DLL hell ever was.

You can't use LD_PRELOAD or other dynamic interception tools.

There are probably more reasons to avoid static linking, but I'm trying to ignore the handful from the popular lists.

Thanks! Most of those seem like a fair trade-off for portability… for an app.

I’m not sure it’s a great idea for an OS as in the OP, but I do like that they claim accurate incremental rebuilds, to ensure everything get updated. Certainly an interesting experiment!

Edit: just to clarify, I meant "app" as in "something that isn't part of the OS/distribution".

The bash-static example alone is proof that the "usefulness" for apps isn't actually there.

Does anyone know how big the base installation is? I couldn't find an answer anywhere, and the link to the QEMU image appears to be broken, currently.

I'm curious how it compares to, say, Alpine with a similar set of packages.

I have an old (2020) .qcow2 lying around that's about 360MB

could you please upload it?

Maybe not all pages are reachable from the root.

If you end up starting a blog, please share it on HN so I can find it :)

Do you have any programming language or UI toolkit preference? That will likely scope your options.

If it's just for you, you could use something simple like Tk (e.g. Python + Tkinter).

It sounds like how the pedals react and one-pedal driving are the reasons they suspect? I was expecting touchscreen-only controls to be mentioned, but for all I know new ICE vehicles are like that too.

to my knowledge almost everything is touchscreen-only in Telsas (correct me if I'm wrong please!) but in everything else I've seen there's at least physical buttons still for some things.

Controls on the wheel or yoke include: turn signals, horn, windshield wipers, high beams, cruise/autopilot/FSD, voice command, and two 5-way scroll wheel things which are somewhat programmable and enable additional options when another button is pressed. By default I think they control audio, cruise speed, and following distance.

Older models have some of the above on stalks.

Beyond the wheel you've got window controls, gear selector, map lights, buttons and levers to open the doors, a gas and brake pedal, I think that's it

That said, you mostly tell the car what to do with voice commands. "Defrost the windows" or "open the glove box" or "drive to Costco" etc.

Edit: Hazard lights too

> new ICE vehicles are like that too.

I’d expect them to be on versus more trained than the general population. Cars are their work tools, they spend a lot of time in there.

people are on their phones driving in every kind of car. Not sure if its relevant that its a touchscreen, even though I prefer older fashioned buttons.

What are some current examples of lean software, esp. related to developing and deploying software?

i3? SourceHut? QuickJS? Edit: BusyBox!

I know it’s an open-ended question, but I’m curious to see thoughts from others.

For context, possibly in reaction to porting an app via Electron, I’ve been trying to repent by finding a minimal development environment for hobby projects. I’m not sure it qualifies as “lean”, but Emacs and SBCL strike a nice balance for me right now.