mu1 VS teliva

I got sick of juggling code that migrated from one category to the other, so I wrote a little script that deals with chopping up a large source file into multiple TUs before feeding them to the compiler.

https://github.com/akkartik/mu1/blob/master/build2

More details: https://news.ycombinator.com/item?id=33574154#33575045

This really speaks to me. Modern software is too hard to assemble from source. If you're shipping sources, every moving part you add increases the odds of something going wrong on other people's computers.

It's worth having some skepticism of tools. By making some operations easy, tools encourage them. Build systems make it easy to bloat software. Package managers make it easy to bloat dependencies. This dynamic explains why Python in particular has such a terrible package management story. It's been around longer than Node or Rust, so if they seem better -- wait 10 years!

For many of my side projects I try to minimize moving parts for anyone (usually the '1' is literally true) who tries them out. I work in Unix, and one thing I built is a portable shell script that acts like a build system while being much more transparent about what it does: https://codeberg.org/akkartik/basic-build

When I use this script my build instructions are more verbose, but I think that's a good thing. They're more explicit for newcomers, and they also impose costs that nudge me to keep my programs minimalist.

You can see this build system evolve to add partial builds and parallel builds in one of my projects:

https://github.com/akkartik/mu1/blob/master/build0

https://github.com/akkartik/mu1/blob/master/build1

https://github.com/akkartik/mu1/blob/master/build2

https://github.com/akkartik/mu1/blob/master/build3

https://github.com/akkartik/mu1/blob/master/build4

Each of these does the same thing for this one repo -- build it -- but adding successively more bells and whistles.

I think providing just the most advanced version, build4, would do my users a disservice. It's also the most likely to break, where build0 is rock solid. If my builds do break for someone, they can poke around and downgrade to a simpler version.

Totally agreed!

Here's a prototype from a few years ago where I tried to make this easier: https://github.com/akkartik/mu1#readme (read just the first few paragraphs)

I still think the full answer lies in this direction.

Thanks for reply and for have shared your project first!

> I think we can refresh some the things that make it powerful with a fresh coat of paint, to make it more accessible to a “younger generation.”

That's what scare me, again in general: I see regular small complaint of modern absurdity, posts like:

- https://tiramisu.bearblog.dev/your-desktop-is-not-a-destinat... | https://news.ycombinator.com/item?id=33838697

- https://mjg59.dreamwidth.org/61535.html

- https://vermaden.wordpress.com/2022/02/07/epitaph-to-laptops...

- https://rsapkf.org/weblog/q2z/

- https://tomcritchlow.com/2022/04/21/new-rss/

- https://jfm.carcosa.net/blog/computing/usenet/ | https://news.ycombinator.com/item?id=33510169

- https://dianne.skoll.ca/projects/remind/ | https://news.ycombinator.com/item?id=28363453

- https://github.com/akkartik/teliva

- https://akiflow.com/

- https://onezero.medium.com/the-document-metaphor-desktop-gui...

- https://den.dev/blog/user-hostile-software/

- https://www.charlieharrington.com/smart-phone-dumb-terminal/

- https://mattmower.com/2021/08/02/what-we-lost/

and COUNTLESS others, similarly many "new stuff"/innovations appear and are actually partial, limited and limiting solutions to problems already solved decades ago in a more broad and superior way.

Emacs itself is a bit horrific in the sense that it's codebase is hard to be kept up by modern developers who have troubles knowing it, but at least represent the classic model. If we lost the memory of the past it will takes decades to reach the level of evolution we have already achieved witch is really a shame.

Anytime I see new software, yours, LogSeq, some "new shiny file manager", Tiidly Wiki and so on, witch actually are a BIG effort to achieve something already existing with far less efforts thanks to an already made ecosystems who makes their development easier I have a sore smile: end users suffer from limits of modern software, DEVELOPERS suffer equally because craft something on top of modern systems it's equally terrible but we seems to be unable on one side to reach again a critical mass of users to being able to innovate again, on the other sides most people simply ignore the past so ignore what's lost.

A stupid example: link an email in SB means essentially or support a specific MUA, tracking it's evolution since breaking changes might happen all the time or add an MUE inside SB. In Emacs it's just a simple function since anything is already there. In Plan 9 to cite a project often considered hostile from and to Emacs write an MUA is damn simple limiting mails to Plan 9 itself, an MUA it's just a specific viewer of some text stream read form some user-configured filesystems mounts and so on.

The sore part is that's I can easy state the above, even in my poor English, but I have no practical solution because resurrecting the classic model for present times demand an effort ONLY a public funded body or a large community can made. We have dismissed "for business reasons" essentially all public research and we have essentially pushed to irrelevance all communities...

I question the need for scale in 90% of the places where the tech industry has cargo-culted it. Clearly I'm still failing to articulate this. Perhaps https://news.ycombinator.com/item?id=30019146#30040616 will help triangulate on what I mean.

> Can you clarify what you see as the alternative? Implementing everything from scratch seems absurd and so costly that there’s no point in considering this an actual option.

Not using, reimplementing and copying are the closest thing to solutions I have right now. You're right that they're not applicable to most people in their current context. I have a day job in tech and have to deal with some cognitive dissonance every day between my day job and my open source research. The one thing I have found valuable to take to my scale-obsessed tech job is to constantly be suspicious of dependencies and constantly ask if the operational burdens justify some new feature. Just switching mindset that way from software as asset to software as liability has, I'd like to believe, helped my org's decision-making.

> We have probably invested dev-millennia into managing copies. This is exactly what source control does. This is not a new area of investment. Merging is a giant pain in the ass and very possibly always will be. Accepting merge pain better come with some huge benefits.

Not all copying is the same. We've learned to copy the letter 'e' so well in our writings that we don't even think about it. In this context, even if I made a tool to make copying easier and merges more reliable, that would just cause people to take on more dependencies which defeats the whole point of understanding dependencies. So tooling would be counter-productive in that direction. The direction I want to focus on is: how can we help people understand the software they've copied into their applications? _That_ is the place where I want tooling to focus. Copying is just an implementation detail, a first, imperfect, heuristic coping mechanism for going from the world we have today to the world I want to move to that has 1000x more forks and 1000x more eyeballs looking at source code. You can see some (very toy) efforts in this direction at https://github.com/akkartik/teliva

> It’s untenable to have, e.g., everyone who works on Windows be an expert in every part of the code.

It's frustrating to say one thing in response to counter-argument A and have someone then bring up counter-argument B because I didn't talk about it right there in the response to counter-argument A. I think this is what Plato was talking about when he ranted about the problems with the newfangled technology of writing: https://newlearningonline.com/literacies/chapter-1/socrates-.... I'm not saying everyone needs to be an expert in everything. I'm saying software should reduce the pressure on people to be experts so that we can late-bind experts to domains. Not every software sub-system should need expertise at the scale at which it is used in every possible context. My Linux laptop doesn't need to be optimized to the hilt the way Google's server farms do. Using the same scheduling algo or whatever in my laptop imposes real costs on my ability to understand my computer, without giving me the benefits Google gets from the algo.

There are options between those possibilities, though. Here's my preferred point[1] in the state space:

It's impossible for people to effectively use software over the long term without learning about its internals. Software can help people learn about its internals.

https://github.com/akkartik/teliva#readme

I work on ways to write programs that help outsiders understand their big picture (rather than insiders understand incoming contributions).

The goal: you (any programmer) should be able to use an open-source program, get an idea for a simple tweak, open it up, orient yourself, and make the change you visualized -- all in a single afternoon.

More details: http://akkartik.name/about

What I have so far: https://github.com/akkartik/teliva

Lately I'm spending a lot of time on the sandboxing model. It's nice to be able to download and run untrusted programs. How to permit this without letting them cause too much damage, by explicitly giving them arbitrarily fine-grained permissions that are still easy to take in at a glance.

Main project page: https://github.com/akkartik/teliva

It's hard. Building Mu has given me more of a flavor for just how hard it is. Some limitations of Mu:

* It still requires firmware. There's a whole lot of C down there. How deep do you want to go?

* No mouse. This is just my own ignorance. I can't get the damn IRQs and interrupts figured out.

* Doesn't work yet on real hardware. I live in Qemu. Debugging that is a whole new set of skills I need to learn.

* No networking, almost no persistent storage. Mu has a very simple and slow driver for ATA disks, but that probably won't suffice on most real-world machine configurations. There's 0 network drivers right now. I probably need a dozen to get any sort of coverage.

The stuff you mentioned around graphics and OS file dialogs, that feels easier once you're willing to put up with constraints like Mu's 1024x768 and so on. But yeah, there's major challenges on this road.

Partly due to these challenges, I've actually started to hedge my bets and make some compromises. My new project is https://github.com/akkartik/teliva which doesn't try to eliminate C, just minimize it. Linux kernel, libc, Lua (12k lines of C), some libraries for https. A gemini client is actually on my todo list there. I think I have everything I need to build it.

with chromatic backgrounds deserve whatever happens to them."

That's a lot of cognitive dissonance in a work about UI design. Let's try to do better in making TUIs mainstream. That requires encouraging people to use the few features terminals _do_ provide.

I've been doing a fair amount of ncurses hacking recently[1], and I prefer to always explicitly specify colors. People won't get their preferred colors by default, but they'll always get a legible configuration by default.

[1] https://github.com/akkartik/teliva

Repo